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Becoming an Accidental Project Manager 


Congratulations... you're the project manager! 


Note:The following is based on, and adapted from, the premise of The 
Education of Jerry by J. Davidson Frame in Managing Projects in 
Organization, John Wiley, New York (1995). 


John picks up the phone before the second ring. It's his boss, Mike Johnson. 
"John, I'd like you to stop by my office right after lunch today." 


John is not really sure why the boss is calling him into his office, which 
makes for a long lunch hour. He knows he's been doing a good job lately. 
As a matter of fact, he knows that he's probably the most technically 
capable person in the group. John's mind begins to race.... Maybe it's an 
award? Could it be a promotion? Countless positive and negative scenarios 
run through John's overworked mind until one o'clock finally rolls around 
and he cautiously enters Mike's office. 


"John, I've got some great news for you," Mike begins. "As you know our 
company is developing a business-to-business (B2B) e-commerce system. 
As part of that initiative, I’d like you to explore the possibility of 

integrating our purchase order process into the B2B e-commerce system." 


Before John could say anything Mike continued, "Congratulations, John, 
I'm assigning you as the project manager. Use anyone you need to help you; 
the important thing is to give me a report on your findings within a month. 
Your preliminary investigation will give us an idea of how we should go 
about computerizing the order processing function at BizNex Inc., and we 
need that information in time for our next quarterly executive meeting.” 


John was delighted with being made the project manager. The B2B project 
was the largest BizNex Inc. had ever implemented, and the order processing 
subproject was one component of the larger B2B project. 


Once developed, the B2B system would enable BizNex Inc. to establish 
seamless connections with its vendors. Although BizNex Inc. already used 
computers in its order processing system, the bulk of transactions entailed 
manual interventions. This caused the order fulfillment function to operate 
slowly and led to errors because the manual interventions were error prone. 
With the new B2B system, customers would enter orders using the internet. 
Once captured by the B2B e-commerce system, the orders would be 
processed entirely by the computer. 


This project provided John with his first real management experience. He 
was hired by BizNex Inc. straight after completing his MBA degree at Rice 
University. During his first two years at BizNex Inc., he was assistant to 
Mike Johnson, Vice President of Operations. Despite the high profile of his 
job and the exposure it gave him to high-level decision making within the 
company, John felt that he wanted to become more involved in the decision 
making process. With the order processing subproject, he was being given 
something tangible to do with significantly more responsibilities. 


John determined to do a good job on his project. He put together a task list. 
From his experiences since leaving college he knew it was important to 
assemble the "Project Staff.” After careful thought he decided he needed a 
business analyst, a procurement specialist, an internet expert, an e- 
commerce expert, a logistics expert, and a representative from each of the 
company’s five divisions. He figured that he and the business analyst would 
be the only full time resources on the project. However, the other team 
members would need to make a fairly substantial commitments to the 
project if it is to be completed in a month. He decided that each would have 
to dedicate 25% of their time to the project. 


Since there would be five divisions represented, John planned that each of 
the five divisional representatives would write a section of the study, 
detailing the impacts of the order processing system on their operations and 
defining whatever order processing needs they have. The business analyst 
would capture and document the business requirements and write the 
technical portions of the report. John’s function would be to coordinate the 
efforts of the others and to integrate all the pieces into a cohesive plan. 


As John started to put his team together, he immediately ran into trouble: he 
was unable to get a business analyst assigned full time to the project. 
Because his division was in the midst of developing the B2B system, all 
business analysts were already over committed. John went to his boss, 
Mike, with his problem, but was simply told that he would just have to 
make do with the resources available on a day-to-day basis. 


John thought his luck was changing when he tried to obtain the 
procurement specialist for his project. After several enquiries someone told 
him he should talk with Doug Black, who worked in the contracts and 
procurement department. Doug was two months away from retirement so 
his workload was being reduced. John reasoned that one month assignment 
on his project would fit in with the plans to ease Doug into retirement. As a 
consequence Doug was assigned full time to the project to help pick up the 
slack of not have a business analyst on the project. 


John next approached the information resource manager located in the 
Information Technology division and told him of his need for an internet 
specialist and e-commerce expert. The resource manager immediately 
assigned Sara Stone to help John with internet matters. Unfortunately, with 
no internal e-commerce system experience, John was told that he would 
have to go to an outside consultant for the e-commerce expertise needed. 


The varying degrees of success John had had so far continued when he tried 
to recruit the representatives from the different divisions. The vice president 
of the information technology (IT) division, Sam Nelson, was nothing like 
what he hoped for. His request for assistance was met with an 
uncomfortable silence. A clearly upset Sam said, “I don’t fully understand 
why you and Mike are playing the lead role on something like this. 
Building an order processing system is basically an information technology 
chore and should be left to the IT experts. I’ve had my team looking into 
the matter of automating the order processing system for months, and now 
you come in here telling me what to do.” He dismissed John saying that he 
would "look into things personally." John noted that he had specifically not 
indicated that he would provide any cooperation. In contrast, John had a 
good reception from the finance division; the vice president of finance, 
Lynn Waters, announced it was about time BizNex Inc. entered into the 


twenty-first century and said she would be glad to assign someone from her 
office to help John on the project. 


Until now, all of his experience at BizNex Inc. had been quite friendly, this 
was a side of the business he had not seen before. As he got back to his 
office, he didn't have any time to consider the implications because Doug 
Black knocked on his door. 


“Listen John,” Doug said rather sheepishly. “As you know, I have just under 
two months until I am out of here. I’d like to help you on this project of 
yours, really I would. I am sure it is important. But let me say I really don’t 
know much about computers and think order processing is horridly dull. I 
don't see why I should put too much effort into something that won't effect 
me. So while I'll work with you, you won't expect too much will you?” 


All of this happened on the Thursday, just three days into the project. To get 
the project moving, John tried to arrange a kick-off meeting of all project 
staff at nine o’clock the following Monday. Since Sam Nelson’s office (IT) 
had not assigned a representative, it would not be represented. The finance 
division representative said he thought it was a great idea, but he would be 
out of town throughout the week so could not attend. The other project staff 
members said they would attend the meeting, but John got the impression 
they were not happy about it. Only Sara Stone, the internet expert, sounded 
interested. John wasn’t sure what he would do about getting the e- 
commerce expert. He would have to talk to Mike Johnson about it. 


All through the weekend, John prepared for the meeting. He put together a 
five page preliminary position paper, identified milestones the team 
members would have to meet, created guidelines for the activities to be 
undertaken and read several journal articles on Internet Technology and 
online order processing. On Monday at nine o’clock, John arrived in the 
conference room and found it empty. By nine-thirty, only two other project 
team members had shown up. Conspicuously absent were Doug Black and 
Sara Stone, both of whom had assured him they would be there. 


Without accomplishing anything, John closed the meeting and returned to 
his office. On his voicemail he found a message from Sara Stone saying that 
she was sorry to have missed the meeting, but her boss in the information 


resources management department (part of the IT division) had told her that 
he was pulling her off the project. 


About an hour later, Mike Johnson called John into his office to tell him 
that he was putting the order processing automation project on hold. He 
said, “Sam went to the CEO and complained that you and I are a couple of 
cowboys, and were running around doing things we had no business doing." 
Mike seemed resigned, and continued, "Sorry John. You win some and lose 
some. Next time we’ll do better right?” 


John mumbled assent then went back to his own office. Closing the door he 
sat at his desk and stared out of the window. What had he done wrong, and 
why had someone told the company CEO that he was some kind of 
amateur. As the implications of this last week settled in, John wondered 
about his future with BizNex Inc. 


So what went wrong? 


The story above is not an isolated incident. Every day, scientists, engineers, 
salespeople, technicians, and countless others are thrust into the role of 
project manager. They're very good at what they do. In fact, they're 
typically the most technically knowledgeable engineers or the most 
successful salespeople. Now they're about to become project managers. 


Actually it's probably appropriate to refer to them by their more popular 
name: accidental project managers. An accidental project manager is a 
person who is placed into the role by organizational necessity and chance, 
rather than by design or through choice of career path. 


If you're an accidental project manager, one of the first things you should do 
is pause to consider whether or not you're cut out to be a project manager 
and try to determine whether it's what you really want to do. Why? Because 
if you do a reasonably good job leading your first project, chances are you'll 
be asked again. And again. And again. In other words, if you're finding 
yourself in the same position as John, you might be embarking upon a new 
career. You'd be wise to consider some of the pros and cons before saying 
yes to that career move. 


The information, tools, and techniques described in this course will move 
you well along in understanding the mechanics of managing projects. But 
it's important that you enter this new world with your eyes wide open. With 
that thought in mind, let's take a closer look at what you might expect to 
experience as a project manager. 


However John may feel about taking on his first project, the truth is that life 
as a project manager can be extremely rewarding. You'll find it to be 
different from almost any other thing you've ever done. It's complex, varied, 
and interesting. If done well, it can lead to a very strong sense of 
accomplishment. These are among the aspects that project managers 
identify as the main draws to the job. 


At the same time, being a project manager will test you in ways you may 
not be able to imagine. You will become a focal point in the organization 
especially on high profile projects. Everyone will look to you for the 
answers, but you must be careful not to try to provide all the answers; after 
all, that's why you have a team. 


Speaking of the team, one of the biggest shifts in behavior (and thinking) 
you'll encounter will be the need to rely upon others to get things done. In 
most cases, that's your team. You'll quickly discover that there's far too 
much for you to do alone, yet delegation will prove to be a challenge for 
you. Empowering others, and then trusting them to follow through, may be 
a bit unsettling. You'll find yourself uncomfortable with the idea that others 
are doing things for which you will be held responsible. You'll have lots of 
responsibility, but you'll be missing the authority often perceived as being 
required to discharge that responsibility. 


John was given the responsibility for getting the job done but had very little 
authority to see to it that his decisions were implemented. This was 
reflected in his problems in recruiting project team members and evidenced 
in the fact that he could exercise only marginal control over Doug Black, 
the procurement specialist and the only other full time member. Project 
professionals typically have little authority to carry out their work. They 
have little or no direct control over those people and things that make the 
difference between project success and failure. Among your most valued 
tools will be the ability to persuade and influence, as you seek to form a 


group of diverse personalities into a unified team with commonalty of 
purpose. 


Unfortunately, not everyone on your team will be as knowledgeable and 
skilled as you would like. Nonetheless, you've got to get the job done using 
whatever resources have been provided. Project manager’s staff is generally 
on temporary loan to them. This is also true of the material resources 
needed for the success of the project. People with specialized skills often 
work on the individual pieces. 


On the B2B sub-project in this story, the team was structured in such a way 
that most of the members would bring their own specialized skills to the 
project, e.g., knowledge of e-commerce, knowledge of the workings of the 
procurement division, internet/technical skills. Often, though, skills are so 
specialized that they are employed only briefly. It is not at all uncommon to 
have the composition of the project team continually changing as the 
project progresses through its life cycle. 


So as long as project professionals are dealing with borrowed resources, 
they have limited control over them. This reality overwhelmed John. The 
case study is full of instances in which he was incapable of getting people 
to do what he needs to have done. 


e He couldn’t get a business analyst assigned full time to his project. 

e His full time resource, Doug, made it clear that he is just treading 
water until his retirement and doesn’t even show up for the kick off 
meeting. 

e Jerry finds a competent colleague in Sara Stone, the internet expert; 
but due to the political dynamics of the situation, she is pulled off the 
project by her boss. 

e BizNex Inc. doesn’t have an e-commerce expert so he will have to hire 
an outside consultant over whom he may not be able to exercise some 
degree of control. 


From John’s perspective, the problem is that although he is the project 
manager, he is not the boss. This would be highly impractical, to be boss, 
John would have to possess control over the career development of all the 


people on working on the project, and in view of the nature of his small 
project, highly impractical. 


Project management lore is full of tales of project managers who were able 
to take the hand that was dealt and turn it into project success. For you to 
succeed, you'll have to rely on your ability to coach, mentor, and motivate, 
in order to get the level of performance you need from those assigned to 
work on your project. 


What will you have to know as a project manager? Well, you'll have to 
know a little bit about just about everything. You'll have to learn to pay 
attention to the details, but not get wrapped up in them. You'll have to make 
countless decisions with insufficient information and despite conflicting 
signals. You'll have to condition yourself to seek acceptable solutions, 
rather than perfect ones. You'll have to blend technical expertise with a keen 
sense of human nature. You'll have to handle administrative matters. 


While you're busy doing your own thing, you'll have to cultivate and 
maintain a smooth working relationship with many other people, both 
inside and outside your organization. Unfortunately, as you seek to carry 
out the objectives of the project, it's unlikely that everyone you encounter 
will be an ally. Organizational politics and reality dictate that not everyone 
will like project management or project managers (that's you!). Many 
people will admire your role, respect your position, and appreciate your 
involvement; others will not. You will need to figure out who's who, really 
fast. 


One final word on John’s unfortunate adventure; a substantial share of his 
problems are rooted by his lack of experience. For example, he does 
nothing to strengthen his authority. Rather than go out on his own in dealing 
with people in other departments at BizNex Inc., he should have worked 
through his vice president, Mike Johnson. He could have drafted an e-mail, 
sent by Mr. Johnson that explained the purpose of his inquiries. In this way, 
he would not have looked like a loose cannon. Because John dealt directly 
with vice presidents in the company, it isn’t really surprising that the 
information technology vice president saw John’s actions as an 
infringement on his territory. 


Project management is both an art and a science. The art is strongly tied to 
the interpersonal aspects; the business of leading people. The science 
includes understanding of processes, tools and techniques. All project 
managers are expected to be very well versed in the science of project 
management. You cannot survive without being knowledgeable in this area. 


We will be addressing the overall project context, encompassing people, 
teams and the organization. We’ ll look at how organizational issues can 
lead to project success or failures and the central importance of politics in 
projects. We’|l talk about strategies on how to cope with these and other 
realities. We’ ll talk about project planning and control and defining the 
needs and requirements analysis, we’ll review some standard tools used for 
enhancing planning and control and finally how to successfully close out a 
project. 


Although we'll focus primarily upon the process, we'll never lose sight of 
the importance of the interpersonal aspects as well as the environmental 
aspects; the people and things that surround your project. 
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History of Project Management 


Could the Great Wall of China, the pyramids, or Stonehenge ([link]) have 
been built without project management? It is possible to say that the 
concept of project management has been around since the beginning of 
history. It has enabled leaders to plan bold and massive projects and manage 
funding, materials and labor within a designated time frame. 
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Stonehenge was erected between 3,000 BC 
and 1,600 BC by no less than three different 
cultures and its orientation on the rising and 
setting sun has always been one of its 
remarkable features. 


In late 19" century, in the United States, large-scale government projects 
were the impetus for making important decisions that became the basis for 
project management methodology such as the transcontinental railroad, 
which began construction in the 1860s. Suddenly, business leaders found 


themselves faced with the daunting task of organizing the manual labor of 
thousands of workers and the processing and assembly of unprecedented 
quantities of raw material. 


Team Work 


This is what can happen without effective 
project management. 


Near the turn of the century, Frederick Taylor ((link]) began his detailed 
studies of work. He applied scientific reasoning to work by showing that 
labor can be analyzed and improved by focusing on its elementary parts that 
introduced the concept of working more efficiently, rather than working 
harder and longer. 


Frederick Taylor (1856-1915). 


Taylor’s associate, Henry Gantt ({link]), studied in great detail the order of 
operations in work and is most famous for developing the Gantt Chart in the 
1910s. A Gantt chart is a popular type of bar chart that illustrates a project 
schedule and have become a common technique for representing the phases 
and activities of a project work breakdown structure, so they can be 
understood by a wide audience ([link]). Although now considered a 
common charting technique, Gantt charts were considered quite 
revolutionary at the time they were introduced. Gantt charts were employed 
on major infrastructure projects including the Hoover Dam and the 
Interstate highway system and are still accepted today as an important tool 
in project. 


Henry Gantt (1861 - 1919). 
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An example of a Gantt chart showing the relationship between a 
series of tasks. 


By the mid Twentieth century, projects were managed on an ad hoc basis 
using mostly Gantt Charts, and informal techniques and tools. During that 
time, the Manhattan project was initiated and its complexity was only 
possible because of project management methods. The Manhattan project 
was the codename given to the Allied effort to develop the first nuclear 


weapons during World War II. It involved over thirty different project sites 
in the US and Canada, and thousands of personnel from US, Canada and 
UK. Born out of a small research program that began in 1939, the 
Manhattan Project would eventually employ 130,000 people and cost a total 
of nearly 2 billion USD and result in the creation of multiple production and 
research sites operated in secret. The project succeeded in developing and 
detonating three nuclear weapons in 1945. 


The 1950s marked the beginning of the modern Project Management era. 
Two mathematical project-scheduling models were developed: 


1. The Program Evaluation and Review Technique or PERT, developed 
by Booz-Allen & Hamilton as part of the United States Navy’s (in 
conjunction with the Lockheed Corporation) Polaris missile submarine 
program. Pert is basically a method for analyzing the tasks involved 
for completing a given project, especially the time needed to complete 
each task, and identifying the minimum time needed to complete the 
total project ((link]). 

2. The Critical Path Method (CPM) developed in a joint venture by both 
DuPont Corporation and Remington Rand Corporation for managing 
plant maintenance projects. The critical path determines the float, or 
schedule flexibility, for each activity by calculating the earliest start 
date, earliest finish date, latest start date, and latest finish date for each 
activity. The critical path is generally the longest full path on the 
project. Any activity with a float time that equals zero is considered a 
critical path task. CPM can help you figure out how long your complex 
project will take to complete and which activities are critical; meaning 
they have to be done on time or else the whole project will take longer. 
These mathematical techniques quickly spread into many private 
enterprises. 


An example of a PERT network chart 
for a seven-month project with five 
milestones. 


Project management in its present form began to take root a few decades 
ago. In the early 1960s, industrial and business organizations began to 
understand the benefits of organizing work around projects. They 
understood the critical need to communicate and integrate work across 
multiple departments and professions. 


The Project Management Institute (PMI) was founded in 1969 by five 
volunteers. Their initial goal was to establish an organization where 
members could share their experiences in project management and to 
discuss issues. Today, PMI is a non-profit project management professional 
association and the most widely recognized organization in terms of 
promoting project management best practices. PMI was formed to serve the 
interests of the project management industry. The premise of PMI is that the 
tools and techniques of project management are common even among the 
widespread application of projects from the software to the construction 
industry. PMI first began offering the PMP certification exam in 1984. 
Although it took a while for people to take notice, now more than 260,000 
individuals around the world hold the PMP designation. 


To help keep project management terms and concepts clear and consistent, 
PMI introduced the Project Management Body of Knowledge (PMBOK) 


Guide in 1987. They updated it in 1996, 2000, 2004, and most recently in 
2009 as the fourth edition. At present, there are more than 1 million copies 
of the PMBOK Guide in circulation. The highly regarded Institute of 
Electrical and Electronics Engineers (IEEE) have adopted it as their project 
management standard. 


In 1999 PMI was accredited as an American National Standards Institute 
(ANSI) standards developer and also has the distinction of being the first 
organization to have its certification program attain International 
Organization for Standardization (ISO) 9001 recognition. In 2008, the 
organization reported more than 260,000 members in over 171 countries. 
PMI also has offices in Washington, D.C., and Beijing, China, as well as 
Regional Service Centers in Singapore, Brussels (Belgium) and New Delhi 
(India). Recently, an office was opened in Mumbai (India). 


What is a Project? 


The starting point in discussing how projects should be properly managed is 
to first understand what a project is and just as importantly what it is not. 


People have been undertaking projects since the earliest days of organized 
human activity. The hunting parties of our prehistoric ancestors were 
projects for example; they were temporary undertakings directed at the goal 
of obtaining meat for the community. Large complex projects have also 
been with us for a long time. The pyramids and the Great Wall of China, 
were in their day of roughly the same dimensions as the Apollo Project to 
send man to the moon. We use the term project frequently in our daily 
conversations. A husband, for example may tell his wife, “My main project 
for this weekend is to straighten out the garage.” Going hunting, building 
pyramids, and fixing faucets all share certain features that make them 
projects. 


A project has distinctive attributes, which distinguish it from ongoing work 
or business operations. Projects are temporary in nature. They are not an 
everyday business process and have definitive start dates and end dates. 
This characteristic is important because a large part of the project effort is 
dedicated to ensuring that the project is completed at the appointed time. To 
do this, schedules are created showing when tasks should begin and end. 
Projects can last minutes, hours, days, weeks, months or years. 


Projects exist to bring about a product or service that hasn’t existed before. 
In this sense, a project is unique. Unique means that this is new, this has 
never been done before. Maybe it’s been done in a very similar fashion 
before but never exactly in this way. For example, Ford Motor Company is 
in the business of designing and assembling cars. Each model that Ford 
designs and produces can be considered a project. The models differ from 
each other in their features and are marketed to people with various needs. 
An SUV serves a different purpose and clientele than a luxury model. The 
design and marketing of these two models are unique projects. However the 
actual assembly of the cars is considered an operation, i.e., a repetitive 
process that is followed for most makes and models. 


In contrast with projects, operations are ongoing and repetitive. They 
involve work that is continuous without an ending date and you often repeat 
the same processes and produce the same results. The purpose of operations 
is to keep the organization functioning while the purpose of a project is to 
meet its goals and to conclude. Therefore, operations are ongoing while 
projects are unique and temporary. 


The project is completed when its goals and objectives are accomplished. It 
is these goals that drive the project and all the planning and implementation 
efforts are undertaken to achieve them. Sometimes projects end when it’s 
determined that the goals and objectives cannot be accomplished or when 
the product or service of the project is no longer needed and the project is 
cancelled. 


A formal definition of a project 


There are many written definitions of a project, however, all of them 
contain the key elements described above. For those looking for a formal 
definition of a project the Project Management Body of Knowledge 
(PMBOK) defines a project as a temporary endeavor undertaken to create 
a unique product, service or result. The temporary nature of projects 
indicates a definite beginning and end. The end is reached when the 
project’s objectives have been achieved or when the project is terminated 
because its objectives will not or cannot be met, or when the need for the 
project no longer exists. 
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Project Characteristics 


When considering whether or not you have a project on your hands, there 
are some things to keep in mind. First, is it a project or ongoing operation? 
Next, if it is a project; who are the stakeholders? And third, what 
characteristics distinguish this endeavor as a project? 


A project has several characteristics: 


e Projects are unique. 

e Projects are temporary in nature and have a definite beginning and 
ending date. 

e Projects are completed when the project goals are achieved or it’s 
determined the project is no longer viable. 

e A successful project is one that meets or exceeds the expectations of 
your stakeholders. 


Consider the following scenario: The VP of marketing approaches you with 
a fabulous idea. (Obviously it must be “fabulous” because he thought of it.) 
He wants to set up kiosks in local grocery stores as mini offices. These 
offices will offer customers the ability to sign up for car and home 
insurance services as well as make their bill payments. He believes that the 
exposure in grocery stores will increase awareness of the company’s 
offerings. He told you that senior management has already cleared the 
project and he’|l dedicate as many resources to this as he can. He wants the 
new kiosks in place in 12 selected stores in a major city by the end of the 
year. Finally, he has assigned you to head up this project. 


Your first question should be “Is it a project?” This may seem elementary, 
but confusing projects with ongoing operations happens often. Projects are 
temporary in nature, have definite start and end dates, result in the creation 
of a unique product or service, and are completed when their goals and 
objectives have been met and signed off by the stakeholders. 


Using these criteria, let’s examine the assignment from the VP of marketing 
to determine if it is a project: 


Is it unique? Yes, because the kiosks don’t exist in the local grocery stores. 
This is a new way of offering the company’s services to its customer base. 
While the service the company is offering isn’t new, the way it is presenting 
its services is. 


Does the product have a limited timeframe? Yes, the start date of this 
project is today, and the end date is the end of next year. It is a temporary 
endeavor. 


Is there a way to determine when the project is completed? Yes, the 
kiosks will be installed and the services will be offered from them. Once all 
the kiosks are intact and operating, the project will come to a close. 


Is there a way to determine stakeholder satisfaction? Yes, the 
expectations of the stakeholders will be documented in the form of 
requirements during the planning processes. These requirements will be 
compared to the finished product to determine if it meets the expectations 
of the stakeholder. 


If the answer is yes to all these questions, then “Houston, we have a 
project”. 
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Project Stakeholders 


A project is successful when it achieves its objectives and meets or exceeds 
the expectations of the stakeholders. But who are the stakeholders? 
Stakeholders are individuals who either care about or have a vested interest 
in your project. They are the people who are actively involved with the 
work of the project or have something to either gain or lose as a result of 
the project. When you manage a project to add lanes to a highway, 
motorists are stakeholders who are positively affected. However, you 
negatively affect residents who live near the highway during your project 
(with construction noise) and after your project with far reaching 
implications (increased traffic noise and pollution). 


Note:Key stakeholders can make or break the success of a project. Even if 
all the deliverables are met and the objectives are satisfied, if your key 
stakeholders aren’t happy, nobody’s happy. 


The project sponsor, generally an executive in the organization with the 
authority to assign resources and enforce decisions regarding the project, is 
a stakeholder. The customer, subcontractors, suppliers and sometimes even 
the Government are stakeholders. The project manager, project team 
members and the managers from other departments in the organization are 
stakeholders as well. It’s important to identify all the stakeholders in your 
project upfront. If you leave out an important stakeholder or their 
department’s function and don’t discover the error until well into the 
project, it could be a project killer. 


[link] shows a sample of the project environment featuring the different 
kinds of stakeholders involved on a typical project. A study of this diagram 
confronts us with a couple of interesting facts. 


e First, the number of stakeholders that project managers must deal with 
assures that they will have a complex job guiding their project through 


the lifecycle. Problems with any of these members can derail the 
project. 

e The diagram also shows that project managers have to deal with 
people external to the organization as well as the internal environment, 
certainly more complex than what a manager in an internal 
environment faces. For example, suppliers who are late in delivering 
crucial parts may blow the project schedule. To compound the 
problem, project managers generally have little or no direct control 
over any of these individuals. 


Government Contractors & 
Subcontractors 


Top Management 
Project Team Members 
Your Manager 


Peers 
Resource Manager 
Internal Customers 


External ; 


Project stakeholders. 


Let’s take a look at these stakeholders and their relationships to the project 
manager. 


Top management 


Top management may include the president of the company, vice 
presidents, directors, division managers, the corporate operating committee, 
and others. These people direct the strategy and development of the 
organization. 


On the plus side, you more likely to have top management support, which 
means it will be easier to recruit the best staff to carry out the project, and to 


acquire needed material and resources; also visibility can enhance PM’s 
professional standing in the company. 


On the minus side, failure can be quite dramatic and visible to all, and if the 
project is large and expensive (most are) the cost of failure will be more 
substantial than for a smaller less visible project. 


Some suggestions in dealing with top management are: 


e Develop in-depth plans and major milestones that must be approved by 
top management during the design phase of the project. 

e Ask top management associated with your project for their information 
reporting needs and frequency. 

e Develop a status reporting methodology to be distributed on a 
scheduled basis. 

¢ Keep them informed of project risks and potential impacts at all times. 


The project team 


Your project team available to project managers on their project or 
borrowed rather than assigned to the project on a full time basis. As project 
manager you need to provide leadership, direction and above all, the 
support to team members as they go about accomplishing their tasks. 
Working closely with the team to solve problems can help you learn from 
the team and build rapport. Showing your support for the project team and 
for each member will help you get their support and cooperation. 


Some difficulties in dealing with project team members include: 


e Since project team members are borrowed and they don’t report to 
you, their priorities may be elsewhere. 

¢ They may be juggling many projects as well as their full time job and 
have difficulty meeting any deadline. 

e Personality conflicts may arise. These may be cause by differences in 
social style or values or they may be the result of some bad experience 
when people worked together in the past. 

e You may find out about missed deadlines when it is too late to recover. 


Managing project team members requires interpersonal skills. Here are 
some suggestions that can help: 


e Involve team members in project planning. 

e Arrange to meet privately and informally with each team member at 
several points in the project, perhaps for lunch or coffee. 

¢ Be available to hear team members concerns at any time. 

e Encourage team members to pitch in and help others when needed. 

e Complete a project performance review for team members. 


Your manager 


Typically the boss decides what our assignment is and who can work with 
us on our projects. Keeping your manager informed will help ensure that 
you get the necessary resources to complete your project. 


e If things go wrong on a project, it is nice to have an understanding and 
supportive boss to go to bat for us if necessary. By supporting your 
manager, you will find your manager will support you more often. 

e Find out exactly how your performance will be measured. 

e When unclear about directions, ask for clarification. 

e Develop a reporting schedule that is acceptable to your boss. 

¢ Communicate frequently. 


Peers 


Peers are people on the project team who are at the same level in the 
organization as you. These people will, in fact, also have a vested interest in 
the product. However, they will have neither the leadership responsibilities 
nor the accountability for the success or failure of the project that you have. 


Your relationship with peers can be impeded by: 


e Inadequate control over peers. 

e Political maneuvering or sabotage. 

e Personality conflict or technical conflict. 

e Envy because your peer may have wanted to lead the project. 


¢ Conflicting instructions from your manager and your peer’s manager. 


Peer support is essential. Because most of us serve our self-interest first, use 
some investigating, selling, influencing and politicking skills here. To 
ensure you have cooperation and support from your peers: 


¢ Get the support of your project sponsor or top management to 
empower you as the project manager with as much authority as 
possible. It’s important that the sponsor makes it clear to the other 
team members that their cooperation on project activities is expected. 

¢ Confront your peer if you notice a behavior that seems dysfunctional, 
such as bad-mouthing the project. 

e Be explicit in asking for full support from your peers. 

e Arrange for frequent review meetings. 

e Establish goals and standards of performance for all team members. 


Resource managers 


Because project managers are in the position of borrowing resources, other 
managers control their resources. So their relationships with people are 
especially important. If their relationship is good, they may be able to 
consistently acquire the best staff and the best equipment for their projects. 
If relations aren’t so good, they may find themselves not able to get good 
people or equipment needed on the project. 


Internal customer 


Internal customers are individuals within the organization who have 
projects that meet the needs of internal demands. The customer holds the 
power to accept or reject your work. Early in the relationship, the project 
manager will need to negotiate, clarify, and document project specifications 
and deliverables. After the project begins, the project manager must stay 
tuned in to the customer’s concerns and issues and keep the customer 
informed. 


Common stumbling blocks when dealing with customers include: 


e A lack of clarity about precisely what is wanted by the customer. 

e A lack of documentation for what is wanted. 

e A lack of knowledge of the customer’s organization and operating 
characteristics. 

e Unrealistic deadlines, budgets, or specifications. 

e Hesitancy to sign off on the project or accept responsibility for 
decisions. 

e Changes in project scope. 


To meet the needs of the customer, client or owner, be sure to do the 
following: 


e Learn the client’s organization’s buzzwords, culture, and business. 

e Clarify all project requirements and specifications in a written 
agreement. 

e Specify a change procedure. 

e Establish the project manager as the focal point of communications in 
the project organization. 


External customer 


External customers are the customers when projects could be marketed to 
outside customers. In the case of Ford Motor Company for example, the 
external customers would be the buyers of the automobiles. 


Government 


Project managers working in certain heavily regulated environment (e.g., 
pharmaceutical, banking industries, etc.) will have to deal with government 
regulators and departments. These can include all or some levels from city, 
through county, state, and federal, to international. 


Contractors, subcontractors, and suppliers 


There are times when organizations don’t have the expertise in house or 
available resources and work is farmed out to contractors or subcontractors. 


This can be a construction management firm, network consultants, 
electricians, carpenters, architects, and in general anyone who is not an 
employee. Managing contractors or suppliers requires many of the skills 
needed to manage full-time project team members. 


Any number of problems can arise with contractors or subcontractors: 


¢ Quality of the work. 
e Cost overruns. 
e Schedule slippage. 


Many projects heavily depend on goods provided by outside suppliers. This 
is true for example of construction projects where lumber, nails, brick and 
mortar come from outside suppliers. 


e If the supplied goods are delivered late or in short supply or of poor 
quality or if the price is greater than originally quoted, the project may 
suffer. 


Depending on the project, managing relationships can consume more than 
half of the project manager’s time. It is not purely intuitive; it involves a 
sophisticated skill set that includes managing conflicts, negotiating, and 
other interpersonal skills. 


The Politics of Projects 


Many times, project stakeholders have conflicting interests. It’s the project 
manager’s responsibility to understand these conflicts and try to resolve 
them. It’s also the project manger’s responsibility to manage stakeholder 
expectations. Be certain to identify and meet with all key stakeholders early 
in the project to understand all their needs and constraints. 


Project managers are somewhat like politicians. Typically, they are not 
inherently powerful, or capable of imposing their will directly to co- 
workers, subcontractors and suppliers. Like politicians, if they are to get 
their way, they have to exercise influence effectively over others. On 
projects, project managers have direct control over very few things; 
therefore their ability to influence others- to be a good politician- may be 
very important 


Here are a few steps a good project politician should follow. However, a 
good rule is that when in doubt, stakeholder conflicts should always be 
resolved in favor of the customer. 


Assess the environment 


Identify all the relevant stakeholders. Because each of these stakeholders 
could derail the project we need to consider their particular interest in the 
project. 


e Once all relevant stakeholders are identified, we try to determine 
where the power lies. 

e In the vast cast of characters we confront, who counts most? 

¢ Whose actions will have the greatest impact? 


Identify goals 


After determining whom the stakeholders are, we should identify their 
goals. 


e What is it that drives them? 


e¢ What is each after? 

e We should also be aware of hidden agendas of goals that are not 
openly articulated. 

e We need to pay special attention to the goals of the stakeholders who 
hold the power. 


Define the problem 


e The facts that constitute the problem should be isolated and closely 
examined. 

e The question should be raised “What is the real situation?” over and 
over. 


What is Project Management? 


You’ve determined that you have a project. What now? The notes you 
scribbled down on the back of the napkin at lunch are a start, but not 
exactly good project management practice. Too often, organizations follow 
Nike’s advice when it comes to managing projects when they “just do it.” 
An assignment is made and the project team members jump directly into the 
development of the product or service requested. In the end the delivered 
product doesn’t meet the expectations of the customer. Unfortunately, many 
projects follow this poorly constructed path and that is a primary 
contributor to why a large percentage of projects don’t meet their original 
objectives defined by performance, schedule, and budget. 


In the United States, more than $250 billion dollars is spent each year on IT 
application development in approximately 175,000 projects. The Standish 
Group (a Boston-based leader in project and value performance research) 
just released the summary version of their 2009 CHAOS Report that tracks 
project failure rates across a broad range of companies and industries 


(Link]). 


Successful = delivered on time, 
on budget, with required 
Challenged = late, features and functions 
overbudget, and/or 
withless than the required 


features and functions 


Failed = cancelled prior 
to completion or 
delivered and never used 


Summary of 2009 Standish Group CHAOS report. 


Jim Johnson, chairman of the Standish Group has stated that “this year’s 
results show a marked decrease in project success rates, with 32% of all 
projects succeeding which are delivered on time, on budget, with required 


features and functions, 44% were challenged which are late, over budget, 
and/or with less than the required features and functions and 24% failed 
which are cancelled prior to completion or delivered and never used.” 


When are companies going to stop wasting billions of dollars on failed 
projects? The vast majority of this waste is completely avoidable; simply 
get the right business needs (requirements) understood early in the process 
and ensure that project management techniques are applied and followed 
and the project activities are monitored. 


Applying good project management discipline is the way to help reduce the 
risks. But keep in mind, having good project management skills does not 
mean you have no problems, it does not mean that risks go away, or that 
there won’t be any surprises. The value of good project management is that 
you have standard processes in place to deal with all contingencies. 


Project Management is the application of knowledge, skills, tools, and 
techniques applied to project activities in order to meet the project 
requirements. Project management is a process that includes planning, 
putting the project plan into action, and measuring progress and 
performance. 


Managing a project includes identifying your project’s requirements; 
writing down what everyone needs from the project. What are the 
objectives for your project? When everyone understands the goal, it’s much 
easier to keep them all on the right path. Make sure you set goals that 
everyone agrees on to avoid team conflicts later on. Understanding and 
addressing the needs of everyone affected by the project means the end 
result of your project is far more likely to satisfy your stakeholders, and last 
but not least, as project manager you will also be balancing the many 
competing project constraints. 


On any project, you will have a number of competing project constraints 
that are competing for your attention. They are cost, scope, quality, risk, 
resources and time. 


¢ Cost is budget approved for the project including all necessary 
expenses needed to deliver the project. Within organizations, project 


managers have to balance between not running out of money and not 
under spending because many projects receive funds or grants that 
have contract clauses with an “use it or lose it” approach to project 
funds. Poorly executed budget plans can result in a last minute rush to 
spend the allocated funds. For virtually all projects, cost is ultimately a 
limiting constraint; few projects can go over budget without eventually 
requiring a corrective action. 

Scope is what the project is trying to achieve, it entails all the work 
involved in delivering the projects outcomes and the processes used to 
produce them. It is the reason and the purpose of the project. 

Quality is the standards and criteria to which the project’s products 
must be delivered for them to perform effectively. First, the product 
must perform to provide the functionality expected, and to solve the 
problem, and deliver the benefit and value expected of it. It must also 
meet other performance requirements, or service levels, such as 
availability, reliability and maintainability, and have acceptable finish 
and polish. Quality on a project is controlled through quality assurance 
(QA) that is the process of evaluating overall project’s performance on 
a regular basis to provide confidence that the project will satisfy the 
relevant quality standards. 

Risk is defined by potential external events that will have a negative 
impact on your project if they occur. Risk refers to the combination of 
the probability the event will occur and the impact on the project if the 
event occurs. If the combination of the probability of the occurrence 
and the impact to the project is too high, you should identify the 
potential event as a risk and put a proactive plan in place to manage 
the risk. 

Resources are required to carry out the project tasks. They can be 
people, equipment, facilities, funding, or anything else capable of 
definition (usually other than labor) required for the completion of a 
project activity. 

Time is defined as the time to complete the project. Time is often the 
most frequent project oversight in developing projects. This is 
reflected in missed deadlines and incomplete deliverables. Proper 
control of the schedule requires the careful identification of tasks to be 
performed, an accurate estimation of their durations, the sequence in 


which they are going to be done, and how people and other resources 
are allocated. 


You may have heard of the term “Triple Constraint” which traditionally 
only consisted of Time, Cost & Scope. These are the primary competing 
project constraints that you have to be aware of most. The triple constraint 
is illustrated in the form of a triangle to visualize the project work and to 
see the relationship between the scope/quality, schedule/time, and 
cost/resource ([link]). 


A schematic of the triple constraint 
triangle. 


In this triangle, each side represents one of the constraints (or related 
constraints) wherein any changes to any one side cause a change in the 
other sides. The best projects have a perfectly balanced triangle. 
Maintaining this balance is difficult because projects are prone to change. 
For example, if scope increases, cost and time may increase 
disproportionately. Alternatively, if the amount of money you have for your 
project decreases, you may be able to do as much, but your time may 
increase. 


Your project may have additional constraints that you are facing, and as the 
project manager you have to balance the needs of these constraints against 


the needs of the stakeholders and against your project goals. For instance, if 
your sponsor wants to add functionality to the original scope you will very 
likely need more money to finish the project or if they cut the budget you 
have to reduce the quality of your scope and if you don’t get the appropriate 
resources to work on your project tasks you will have to extend your 
schedule because the resources you have take much longer to finish the 
work. 


You get the idea; they are all dependent on each other. Think of all of these 
constraints as the classic carnival game of Whac-a-mole ([link]). Each time 
you try to push one mole back in the hole, another one pops out. The best 
advice is to aE on your project team to keep a moles in place! 


Go to 
www.dorneypark.com/public/online_fun/mole.cf 
m to play Whac-a-mole. 


Here is an example of a project that cut quality because the project costs 
were fixed. The P-36 oil platform ([link]) was the largest floating 
production platform in the world capable of processing 180,000 barrels of 
oil per day and 7.2 million cubic meters of gas per day. Located in the 
Roncador Field, Campos Basin, Brazil the P-36 was operated by Petrobras. 


The Petrobras P-36 oil platform. 


In March 2001, the P-36 was producing around 84,000 barrels of oil and 1.3 
million cubic meters of gas per day when it became destabilized by two 
explosions and subsequently sank in 3900 feet of water with 1650 short 
tons of crude oil remaining on board, killing 11 people. 


The sinking is attributed to a complete failure in quality assurance and 
pressure for increased production led to corners being cut on safety 
procedures. It is listed as one of the most expensive accidents with a price 
tag of $515,000,000. 


The following quote is from a Petrobras executive, citing the benefits of 
cutting quality assurance and inspection costs on the project, while the 
accompanying pictures are the result of this proud achievement in project 
management by Petrobras. 


"Petrobras has established new global benchmarks for 
the generation of exceptional shareholder wealth through 
an aggressive and innovative program of cost cutting on 

its P36 production facility." 


"Conventional constraints have been successfully 
challenged and replaced with new paradigms appropriate 
to the globalized corporate market place." 


"Through an integrated network of facilitated workshops, 
the project successfully rejected the established 
constricting and negative influences of prescriptive 
engineering, onerous quality requirements, and outdated 
concepts of inspection and client control." 


"Elimination of these unnecessary straitjackets has 
empowered the project's suppliers and contractors to 
propose highly economical solutions, with the win-win 
bonus of enhanced profitability margins for themselves." 


"The P36 platform shows the shape of things to come in 
the unregulated global market economy of the 21° 
century." 


The dynamic trade-offs between the project constraint values has been 
humorously but accurately described in [link]. 


"We can do GOOD, QUICK and CHEAP work. 


You can have any two but not all three. 


1. GOOD QUICK work won't be CHEAP. 
2. GOOD CHEAP work won't be QUICK. 
3. QUICK CHEAP work won't be GOOD." 


A sign seen at an automotive repair shop. 
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Project Management Areas of Expertise 


In order for you as the project manager to manage the competing project constraints and to 
manage the project as a whole, there are some areas of expertise that you should bring onto 
the project team ([link]). They are the application area of knowledge; standards and 
regulations in your industry, understanding the project environment, and you must have 
general management knowledge and interpersonal skills. It should be noted that the 
industry expertise is not in a certain field but the expertise in order to run the project. So 
while knowledge of the type of industry is important you will have a project team 
supporting you in this endeavor. For example, if you are managing a project that is building 
an oil platform, you would not be expected to have a detailed understanding of the 
engineering since your team will have mechanical and civil engineers who will provide the 
appropriate expertise, however, it would definitely help if you understand this type of work. 


Let’s take a look at each of these areas in more detail. 


Areas of expertise that a project 
manager should bring to the project 
team. 


Application knowledge; standards & regulations 


By standards, we mean guidelines or preferred approaches that are not necessarily 
mandatory. In contrast, when referring to regulations we mean mandatory rules that must be 
followed such as Government imposed requirements through laws. It should go without 
saying that as a professional, you’re required to follow all applicable laws and rules that 
apply to your industry, organization, or project. Every industry has standards and 
regulations. Knowing which ones effect your project before you begin work will not only 
help the project to unfold smoothly, but will also allow for effective risk analysis. 


Some projects require specific skills in certain application areas. Application areas are 
made up of categories of projects that have common elements. They can be defined by: 
industry group (pharmaceutical, financial, etc), by department (accounting, marketing, 
legal, etc), by technical (software development, engineering, etc), or management 
(procurement, research, & development, etc) specialties. These application areas are usually 
concerned with disciplines, regulations and the specific needs of the project, the customer, 
or the industry. For example, most government agencies have specific procurement rules 


that apply to their projects that wouldn’t be applicable in the construction industry. The 
pharmaceutical industry is interested in regulations set forth by the Food and Drug 
Administration, whereas the automotive industry has little or no concern for either of these 
types of regulations. You need to stay up-to-date regarding your industry so that you can 
apply your knowledge effectively. Today’s fast paced advances can leave you behind fairly 
quickly if you don’t stay abreast on current trends. 


Having some level of experience in the application area you’re working in will give you an 
advantage when it comes to project management. While you can call in experts who have 
the application area knowledge, it doesn’t hurt for you to understand the specific aspects of 
the application areas of your project. 


Understanding the project environment 


There are many factors that need to be understood within your project environment ([link]). 
At one level you need to understand your project environment by thinking in terms of the 
cultural and the social environment. In this region we think of people, demographics and 
education. The international and political environment is where you need to understand 
about different countries cultural influences. Then we move on to the physical environment; 
here we think about time zones, think about different countries and how differently your 
project will be executed whether it is just in your country or whether you have an 
international project team that is distributed throughout the world in five different countries. 


Project Environment 
Cultural Social 
International Political 


Physical 


The important factors to 
consider within the project 
environment. 


Of all the factors the physical ones are the easiest to understand, and it is the cultural and 
international factors that are often misunderstood or ignored. How we deal with clients, 
customers, or project members from other countries can be critical to the success of the 
project. For example, the culture of the United States values accomplishments and 
individualism. Americans tend to be informal and call each other by first names, even if 
having just met. Europeans tend to be more formal, using surnames instead of first names in 
a business setting, even if they know each other well. In addition, their communication style 
is more formal than in the US, and while they tend to value individualism, they also value 


history, hierarchy, and loyalty. The Japanese, on the other hand, tend to communicate 
indirectly and consider themselves part of a group, not as individuals. The Japanese value 
hard work and success, as most of us do. 


How a product is received can be very dependent on the international cultural differences. 
For example, in the nineties, when many large American and European telecommunications 
companies were cultivating new markets in Asia, their customer’s cultural differences often 
produced unexpected situations. Western companies planned their telephone systems to 
work the same way in Asia as they did in Europe and America. But the protocol of 
conversation was different. Call-waiting, a popular feature in the West, is considered 
impolite in some parts of Asia. This cultural blunder could have been avoided had the team 
captured the project environment requirements and involved the customer. 


It is often the simplest things that can cause trouble since unsurprisingly in different 
countries people do things differently. One of the most notorious examples of this is also 
one of the most simple: date formats. What day and month is 2/8/2009? Of course it 
depends where you come from; in North America it is February 8" while in Europe (and 
much of the rest of the world) it is 2"¢ August. Clearly, when schedules and deadlines are 
being defined it is important that everyone is clear on the format used. 


The diversity of practices and cultures and its impact on products in general and on 
software in particular, goes well beyond the date issue. You may be managing a project to 
create a new website for a company that sells products worldwide. There are language and 
presentation style issues to take into consideration; converting the site into different 
languages isn’t enough. It is obvious to ensure that the translation is correct, however, the 
presentation layer will have its own set of requirements for different cultures. The left side 
of a web site may be the first focus of attention for an American; the right side would be the 
initial focus for anyone from the Middle East, as both Arabic and Hebrew are written from 
right to left. Colors also have different meanings in different cultures. White, which is a 
sign of purity in America (e.g., a bride’s wedding dress), and thus would be a favored 
background color in North America, signifies death in Japan (e.g., a burial shroud). [link] 
summarizes different meanings of common colors. 


United : 
Color Gintes China Japan Egypt France 
Red paneer Happiness Ber, Death Aristocracy 
stop danger 


Blue Sadness, Heavens, Villainy Virtue, Freedom, 


melancholy clouds faith, truth peace 


Novice, pane Future, | Fertility, oo 
Green : dynasty, youth, Criminality 
apprentice strength 
heavens energy 
Yellow Cowardice Birth, Grace, Happiness, Temporary 
wealth nobility prosperity 
White Purity mason Death Joy Neutrality 
purity 


The meaning of colors in various cultures. Adapted from P. Russo and S. Boor, How Fluent 
is Your Interface? Designing for International Users, Proceedings of the INTERACT '93 
and CHI '93, Association for Computing Machinery, Inc. (1993). 


Project managers in multicultural projects must appreciate the culture dimensions and try to 
learn relevant customs, courtesies, and business protocols before taking responsibility for 
managing an international project. A project manager must take into consideration these 
various cultural influences and how they may affect the project’s completion, schedule, 
scope and cost. 


Management knowledge & skills 


As the project manager you have to rely on your project management knowledge and your 
general management skills. In this area we are thinking of items like your ability to plan the 
project, to execute the project properly and of course to control the project and bring it to a 
successful conclusion with the ability to guide the project team while achieving project 
objectives and balancing the project constraints. 


There is more to project management than just getting the work done. Inherent to the 
process of project management are the general management skills that allow the project 
manager to complete the project with some level of efficiency and control. In some 
respects, managing a project is similar to running a business: there are risk and rewards, 
finance and accounting activities, human resource issues, time management, stress 
management, and a purpose for the project to exist. General management skills are needed 
in just about every project. 


Interpersonal skills 


Last but not least you also have to bring the ability onto the project to manage personal 
relationships as well as dealing with issues as they arise. Here were talking about your 
interpersonal skills as shown in [link]. 


Interpersonal Skills 
Communication Influence 
Leadership Motivation 
Negotiation Problem solving 


Interpersonal skills required of a 
project manager. 


Communication 


Project managers spend 90% of their time communicating. Therefore they must be good 
communicators, promoting clear unambiguous exchange of information. As a project 
manager, it is your job to keep a number of people well informed. It is essential that your 
project staff know what is expected of them: what they have to do, when they have to do it, 
and what budget and time constraints and quality specification they are working towards. If 
project staff does not know what their tasks are, or how to accomplish them, then the entire 
project will grind to a halt. If you do not know what the project staff is (or often is not) 
doing then you will be unable to monitor project progress. Finally, if you are uncertain of 
what the customer expects of you, then the project will not even get off the ground. Project 
communication can thus be summed up as who needs what information and when. 


All projects require sound communication plans, but not all projects will have the same 
types of communication or the same methods for distributing the information. For example, 
will information be distributed via mail or e-mail, is there a shared web site, or are face-to- 
face meetings required? The communication management plan documents how the 
communication needs of the stakeholders will be met, including the types of information 
that will be communicated, who will communicate it, who receives the communication, the 
methods used to communicate, the timing and frequency, the method for updating the plan 
as the project progresses, escalation process, and a glossary of common terms. 


Influence 


Project management is about getting things done. Every organization is different in its 
policies, modes of operations and underlying culture. There are political alliances, differing 
motivations, conflicting interest, and power struggles within every organization. A project 
manager must understand all of the unspoken influences at work within an organization. 


Leadership 


Leadership is the ability to motivate and inspire individuals to work towards expected 
results. Leaders inspire vision and rally people around common goals. A good project 
manager can motivate and inspire the project team to see the vision and value of the project. 
The project manager as a leader can inspire the project team to find a solution to overcome 
the perceived obstacles to get the work done. 


Motivation 


Motivation helps people work more efficiently and produce better results. Motivation is a 
constant process that the project manager must have to help the team move towards 
completion with passion and a profound reason to complete the work. Motivating the team 
is accomplished by using a variety of team building techniques and exercises. Team 
building is simply getting a diverse group of people to work together in the most efficient 
and effective manner possible. This may involve management events as well as individual 
actions designed to improve team performance. 


Recognition and rewards are an important part of team motivations. They are formal ways 
of recognizing and promoting desirable behavior and are most effective when carried out by 
the management team and the project manager. Consider individual preferences and cultural 
differences when using rewards and recognition. Some people don’t like to be recognized in 
front of a group; others thrive on it. 


Negotiation 


Project managers must negotiate for the good of the project. In any project, the project 
manager, the project sponsor, and the project team will have to negotiate with stakeholders, 
vendors, and customers to reach a level of agreement acceptable to all parties involved in 
the negotiation process. 


Problem solving 


Problem solving is the ability to understand the heart of a problem, look for a viable 
solution, and then make a decision to implement that solution. The premise for problem 
solving is problem definition. Problem definition is the ability to understand the cause and 
effect of the problem; this centers on root cause analysis. If a project manager treats only 
the symptoms of a problem rather than its cause, the symptoms will perpetuate and continue 
through the project life. Even worse treating a symptom may result in a greater problem. 
For example, increasing the ampere rating of a fuse in your car because the old one keeps 
blowing does not solve the problem of an electrical short that could result in a fire. Root 
cause analysis looks beyond the immediate symptoms to the cause of the symptoms, which 


then affords opportunities for solutions. Once the root of a problem has been identified, a 
decision must be made to effectively address the problem. 


Solutions can be presented from vendors, the project team, the project manager or various 
stakeholders. A viable solution focuses on more than just the problem; it looks at the cause 
and effect of the solution itself. In addition, a timely decision is needed or the window of 
opportunity may pass and then a new decision will be needed to address the problem. As in 
most cases, the worst thing you can do is nothing. 


All of these interpersonal skills will be utilized in all areas of project management. Start 
practicing now because its guaranteed that you’I!l need these skills on your next project. 


The Project Life Cycle 


The project manager and project team have one shared goal: to carry out the 
work of the project for the purpose of meeting the project’s objectives. 
Every project has beginnings, a middle period during which activities move 
the project toward completion, and an ending (either successful or 
unsuccessful). A standard project typically has the following four major 
phases (each with its own agenda of tasks and issues): initiation, planning, 
execution, and closure. Taken together, these phases represent the path a 
project takes from the beginning to its end and are generally referred to as 
the project life cycle ({link]). 


ct 
initiation 


Project 
communication 


The four phase of the project life 
cycle. Adapted from J. Westland, The 
Project Management Lifecycle, Kogan 
Page Limited (2006). 


Initiation phase 


During the first of these phases, the initiation phase, the project objective or 
need is identified; this can be a business problem or opportunity. An 
appropriate response to the need is documented in a business case with 
recommended solution options. A feasibility study is conducted to 
investigate whether each option addresses the project objective and a final 
recommended solution is determined. Issues of feasibility (“can we do the 
project?”) and justification (“should we do the project?”) are addressed. 


Once the recommended solution is approved, a project is initiated to deliver 
the approved solution and a project manager is appointed. The major 
deliverables and the participating work groups are identified and the project 
team begins to take shape. Approval is then sought by the project manager 
to move on the detailed planning phase. 


Planning phase 


The next phase, the planning phase, is where the project solution is further 
developed in as much detail as possible and you plan the steps necessary to 
meet the project’s objective. In this step, the team identifies all of the work 
to be done. The project’s tasks and resource requirements are identified, 
along with the strategy for producing them. This is also referred to as scope 
management. A project plan is created outlining the activities, tasks, 
dependencies and timeframes. The project manager coordinates the 
preparation of a project budget; by providing cost estimates for the labor, 
equipment and materials costs. The budget is used to monitor and control 
cost expenditures during project execution. 


Once the project team has identified the work, prepared the schedule and 
estimated the costs, the three fundamental components of the planning 
process are complete. This is an excellent time to identify and try to deal 
with anything that might pose a threat to the successful completion of the 
project. This is called risk management. In risk management, “high-threat” 
potential problems are identified along with the action that is to be taken on 
each high threat potential problem, either to reduce the probability that the 
problem will occur or to reduce the impact on the project if it does occur. 
This is also a good time to identify all project stakeholders, and to establish 


a communication plan describing the information needed and the delivery 
method to be used to keep the stakeholders informed. 


Finally, you will want to document a quality plan; providing quality targets, 
assurance, and control measures along with an acceptance plan; listing the 
criteria to be met to gain customer acceptance. At this point, the project 
would have been planned in detail and is ready to be executed. 


Execution phase 


During the third phase, the execution phase, the project plan is put into 
motion and performs the work of the project. It is important to maintain 
control and communicate as needed during execution. Progress is 
continuously monitored and appropriate adjustments are made and recorded 
as variances from the original plan. In any project a project manager will 
spend most of their time in this step. During project execution, people are 
carrying out the tasks and progress information is being reported through 
regular team meetings. The project manager uses this information to 
maintain control over the direction of the project by measuring the 
performance of the project activities comparing the results with the project 
plan and takes corrective action as needed. The first course of action should 
always be to bring the project back on course, i.e., to return it to the original 
plan. If that cannot happen, the team should record variations from the 
original plan and record and publish modifications to the plan. Throughout 
this step, project sponsors and other key stakeholders should be kept 
informed of project status according to the agreed upon frequency and 
format. The plan should be updated and published on a regular basis 


(Link). 


IS YOUR a 
PROJECT INA 
GOOD SHAPE? 


START! 
YEARS AGO AND NO 
APPARENTLY ONE HAS STOPPED 
US YET 


One year in a project — Day 19. 


Status reports should always emphasize the anticipated end point in terms 
of cost, schedule and quality of deliverables. Each project deliverable 
produced should be reviewed for quality and measured against the 
acceptance criteria. Once all of the deliverables have been produced and the 
customer has accepted the final solution, the project is ready for closure. 


Closure phase 


During the final closure, or closeout phase, the emphasis is on releasing the 
final deliverables to the customer, handing over project documentation to 
the business, terminating supplier contracts, releasing project resources and 
communicating the closure of the project to all stakeholders. The last 
remaining step is to conduct lessons learned studies; to examine what went 
well and what didn’t. Through this type of analysis the wisdom of 
experience is transferred back to the project organization, which will help 
future project teams. 
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Project Initiation 


The project initiation phase is the first phase within the project management 
life cycle, as it involves starting up a new project. Within the initiation 
phase, the business problem or opportunity is identified, a solution is 
defined, a project is formed, and a project team is appointed to build and 
deliver the solution to the customer. A business case is created to define the 
problem or opportunity in detail and identify a preferred solution for 
implementation. The business case includes: 


e A detailed description of the problem or opportunity 

A list of the alternative solutions available 

e An analysis of the business benefits, costs, risks and issues 
e A description of the preferred solution 

e A summarized plan for implementation 


The project sponsor then approves the business case, and the required 
funding is allocated to proceed with a feasibility study. It is up to the project 
sponsor to determine if the project is worth undertaking and whether the 
project will be profitable to the organization. The completion and approval 
of the feasibility study triggers the beginning of the planning phase. The 
feasibility study may also show that the project is not worth pursuing and 
the project is terminated; thus the next phase never begins. 


All projects are created for a reason. Someone identifies a need and devises 
a project to address that need. How well the project ultimately addresses 
that need defines the project’s success or failure. 


The success of your project depends on the clarity and accuracy of your 
business case and whether people believe they can achieve it. Whenever 
you consider past experience, your business case is more realistic; and 
whenever you involve people in the business case’s development, you 
encourage their commitment to achieving it. 


Often the pressure to get results encourages people to go right into 
identifying possible solutions without fully understanding the need; what 
the project is trying to accomplish. This strategy can create a lot of 
immediate activity but it also creates significant chances for waste and 


mistakes if the wrong need is addressed. One of the best ways to gain 
approval for a project is to clearly identify the project’s objectives and 
describe the need or problem for which the project will provide a solution. 


For most of us, being misunderstood is a common occurrence, something 
that happens on a daily basis. At the restaurant the waiter brings us our 
dinner and we note that the baked potato is filled with sour cream, even 
though we expressly requested “no sour cream”. Projects are filled with 
misunderstandings between customers and project staff. What the 
customer’s order (or more accurately what they think they order) is often 
not what they get. This is illustrated in a popular cartoon ({link]) called “I 
know that’s what I said, but it’s not what I meant!” The cartoon 
demonstrates the importance of establishing clear objectives. 


How the project was. ‘What operations installed How the customer was billed How it was supported What the customer really 
documented needed 


I know that’s what I said, but it’s not what I meant! 


The need for establishing clear project objectives cannot be overstated. An 
objective or goal lacks clarity if, when shown to five people, it is interpreted 
in multiple ways. Ideally, if an objective is clear, you can show it to five 
people who, after reviewing it, hold a single view about its meaning. The 
best way to make an objective clear is to state it such a way that it can be 
verified. Building in measures can do this. It is important to provide 
quantifiable definitions to qualitative terms. 


For example, an objective of the team principle (project manager) of a 
Formula 1 racing team may be that their star driver, “finish the lap as fast as 
possible.” That objective is filled with ambiguity. 


¢ How fast is “fast as possible?” Does that mean the fastest lap time (the 
time to complete one lap) or does it mean the fastest speed as the car 
crosses the start/finish line (that is at the finish of the lap)? 

e By when should the driver be able to achieve the objective? It is no use 
having the fastest lap after the race has finished, and equally the fastest 
lap does not count for qualifying, and therefore grid (starting) position, 
if it is performed during a practice session. 


The ambiguity of this objective can be seen from the following example. 
The race lap record at the Circuit de Monaco of 1 min 14.439 sec was 
achieved by Ferrari’s Michael Schumacher in 2004 ([link]). However, he 
achieved this on lap 23 of the race, but crashed on lap 45 of a 77 lap race! 
So while he achieved a fastest lap and therefore met the specific project 
goal of “finish the lap as fast as possible”, it did not result in winning the 
race, Clearly a different project goal. In contrast, the fastest qualifying time 
at the same event was by Renault’s Jarno Trulli (1 min 13.985 sec), which 
gained him pole position for the race, in which he went on to win ([link]). 
In his case he also achieved the specific project goal of “finish the lap as 
fast as possible”, but also the larger goal of winning the race! 


Despite achieving the project goal of the 
“finish the lap as fast as possible” Ferrari’s 
Michael Schumacher crashed 21 laps later 

and did not finish the race. 


Renault’s Jarno Trulli celebrating his win at 
the 2004 Monaco Grand Prix. 


The objective can be strengthened considerably if it is stated as follows: “To 
be able to finish the 3.340 km lap at the Circuit de Monaco at the Monaco 
Grand Prix in 1 min 14.902 sec or less, during qualifying on 23" May, 
2009. This was the project objective achieved by Brawn GP’s Jenson 
Button ([link]). 


Jenson Button took his Brawn GP car to 
pole position at the Monaco Grand Prix with 
a lap time of 1 min 14.902 sec. He also went 

on to with the race, even though he did not 
achieve that lap time during the race. 


There is still some ambiguity in this objective; for example, it assumes the 
star driver will be driving the team’s race car and not a rental car from 
Hertz! However, it clarifies the team principal’s intent quite nicely. It should 
be noted that a clear goal is not enough. It must also be achievable. The 
team principal’s goal becomes unachievable, for example, if he changes it 
to require his star driver finish the 3.340 km lap in 30 seconds or less. 


To ensure the project’s objectives are achievable and realistic, they must be 
determined jointly by managers and those who perform the work. Realism 
is introduced because the people who will do the work have a good sense of 
what it takes to accomplish a particular task. In addition, this process 
assures some level of commitment on all sides; management expresses its 


commitment to support the work effort and worker demonstrate their 
wiliness to do the work. 


Imagine you are an office manager and you have contracted a painter to 
paint your office. Your goal or objective is to have the office painted a 
pleasing blue color. Consider the following conversation that occurs after 
the job was finished: 


Not only did you paint my office walls blue, 
but you painted the ceiling blue as well! 


You asked me to 
paint the room blue, 
and now you've gota 
blue room. 


Office Manager Contractor 


But the ceiling is oppressive! Ceilings should 
never be the same color as the walls. They 
should always be a lighter color. 


You asked for a blue room. 
You're lucky | didn’t paint 
the floor blue as well. 


Office Manager Contractor 


The consequence of not making your objective 
clear. 


This conversation captures in a nutshell the essence of a major source of 
misunderstandings on projects: The importance of setting clear objectives. 
The office manager’s description of how he wanted the room painted meant 
one thing to him and another to the painter. As a consequence, the room 
was not painted to the office manager’s satisfaction. Had his objective been 
more clearly defined, he probably would have had what he wanted. 
Exercise: 


Problem: 


How could you make the objective for painting a room clear such that 
the office manager gets what he wanted? 


Solution: 


The floor and all furniture will be covered by drop cloths prior to 
painting each of the 4 office walls, not including the door, base-boards, 
crown molding, window frames, windows, light switches, or power 
outlets that will be masked with painters tape. The walls should be 
painted using Behr paint in Sapphire Berry #550C-2 in the semi-gloss 
sheen, using a nylon/polyester 3” inch wide brush using a vertical 
brush stroke, applying two coats of paint, allowing 16 hours between 
coats, and be completed by Friday, November 7 including removal of 
all protective tape and drop cloths. 


Of course this assumes the contractor knows which office to paint! But 
you get the idea. 


An Example of a Project Charter 
Introduction 


Overview of the Project 


Provide a simple but precise statement of the project. 


Example: 
Rice University is planning to create a store to sell computer supplies. 


Purpose of the Project Charter 


This Project Charter outlines the purpose, objectives, and scope of the 
project. The purpose of a Project Charter is: 


e to provide an understanding of the project, the reason it is being 
conducted and its justification 

e to establish early on in the project the general scope 

e to establish the project manager and his or her authority level 


A note of who will review and approve the Project Charter needs to be 
included. 


Example: 
The Project Charter will be reviewed by the project team and approved. 
The final approval will be the Dean of Undergraduate Studies. 


Project Objective and Scope 


Objective 

The objective of the project should “clearly stated” and contain a “measure” 
of how to assess whether they have been achieved. It should be realistic, 
and include the objectives. It should follow the SMART protocol: 


e Specific (get into the details) 

e Measurable (use quantitative language so that you know when you are 
finished) 

e Acceptable (to stakeholders) 

e Realistic (given project constraints) 

e Time based (deadlines, not durations) 


Example: 

The objective of this project is to implement a campus store that is ready to 
sell computer supplies such as memory sticks, mouse pads, cables, etc. 
when class starts in August 2010, with enough inventory to last through the 
first two weeks of classes. 


Scope 


The scope of the project should be listed. 


Example: 
The scope of the Rice’s school supplies store project includes the activities 
listed below: 


e Determine what supplies will be sold in the store 

e Establish competitive prices for the computer supplies 

e Source and secure supply vendors 

Establish marketing, procurement, operations and any other necessary 
departments, schools, centers and institutes. 


It is equally important to include in the scope what is not included in the 
project. 


Example: 
The scope of the project does not include: 


e Development of any other school store departments 
e Store design or construction 


Major Milestones 


A list of the milestones that are needed. 


Example: 


e All vendors selected 

e Contracts or orders complete with all vendors 
e Supplies delivered to the store 

e Pricing determined 


Major Deliverables 


A list of the major deliverables that will result from the project are 
described. 


Example: 


e Procurement of supplies 

e Establishment of operations, procurement, marketing and other teams 

e Store supplies stocked and displayed 

e Store staffing completed, including work schedules 

e Establishment of store operations policies, including hours of 
operation 


Assumptions 


The assumptions in creating the project are to be outlined. 


Example: 


¢ Only computer supplies will be sold in the store. 

e Supplies customers will be the Rice University student body and 
faculty 

e Rice University students will manage the project and be responsible 
for ongoing operations. 

e A store sponsor from the University faculty or staff will be assigned 
to mentor students and to provide oversight. 

e Store hours of operation will be approved by the Rice University 
students or store sponsor. 

e Supply deliveries will be arranged or the store sponsor will pick them 
up with students. 

e Students will be empowered to contact vendors for order placement 
and inquiries via telephone. 


Constraints 


It is important to define any and all constraints on the project or those 
working on the project 


Example: 


e Student availability to meet for project planning is limited to school 
hours. 

e The Rice University Student Association will be responsible for the 
creation and operation of the store. 

e Software is not available for project planning and control. 


Business Need or Opportunity 


Provide a concise statement of the business need or opportunity that led to 
the creation of the project. 


Example: 

The goal of this project is to provide income for the Rice Student Center 
while supplying necessary items to students and faculty at competitive 
prices. The school store will be a convenience to students since necessary 
supplies will be available on campus. This will help students to learn to 
manage their personal supplies. 


Preliminary Cost for the Project 


A statement is to be provided indicating how the cost of the project will be 
defined and controlled. 


Example: 
The procurement team will assemble a proposal based on expected costs 
for review by the Dean of Undergraduate Studies. 


Project Charter Acceptance 


The names, titles, and signature lines of the individuals who will sign-off on 
the Project Charter is provided. 


Example: 


Approver for Rice University : 


Prof. John S. Hutchinson Date 
Dean of Undergraduate Studies 


Project Manager Approval: 


Merrie Barron Date 
Project Manager 


Project Planning 


After the project has been defined and the project team has been appointed, 
you are ready to enter the second phase in the project management life 
cycle: the detailed project planning phase. 


Project planning is the heart of the project life cycle, and tells everyone 
involved where you’re going and how you’re going to get there. The 
planning phase is where the project plans are documented, the project 
deliverables and requirements defined, and the project schedule created. It 
involves creating a set of plans to help guide your team through the 
execution and closure phases of the project. The plans created during this 
phase will help you to manage time, cost, quality, change, risk and related 
issues. It will also help you manage staff and external suppliers, to ensure 
that you deliver the project on time and within schedule. 


The project planning phase is often the most challenging phase for a project 
manager, as you need to make an educated guess of the staff, resources and 
equipment needed to complete your project. You may also need to plan your 
communications and procurement activities, as well as contract any 3rd 
party suppliers. 


The purpose of the project planning phase is: 


e Establish business requirements. 

e Establish cost, schedule, list of deliverables and delivery dates. 
e Establish resource plan. 

e Get management approval and proceed to the next phase. 


The basic processes of the project planning are: 


¢ Scope planning specifies the in-scope requirements for the project and 
facilitates creating the work breakdown structure. 

¢ Preparing the work breakdown structure specifies the breakdown 
of the project into tasks and sub tasks. 

¢ Project schedule development specifies the entire schedule of the 
activities detailing their sequence of execution. 


¢ Resource planning specifies who will do what work at which time of 
the project and if any special skills are needed to accomplish the 
project tasks. 

¢ Budget planning specifies the budgeted cost to be incurred in the 
completion of the project. 

¢ Procurement planning focuses on dealing with vendors outside of 
your company 

e¢ Risk management planning charts the risks, contingency plan and 
mitigation strategies. 

¢ Quality planning for quality assurance to be applied to the project. 

e¢ Communication planning on the communication strategy with all 
project stakeholders. 


The planning phase refines the project’s objectives gathered during the 
initiation phase and plans the steps necessary to meet those objectives by 
further identifying the specific activities and resources required to complete 
the project. Now that these objectives have been recognized, they must be 
clearly articulated entailing an in-depth scrutiny of the recognized 
objective. With such scrutiny, our understanding of the objective will 
change. Often the very act of trying to describe something precisely gives 
us a better understanding of what we are looking at. This articulation serves 
as the basis for the development of requirements. What this means is that 
after an objective has been clearly articulated (clearly stated) we can go 
about the business of stipulating in concrete terms what we have to do to 
achieve it. Obviously, if we do a poor job of articulating the objective, our 
requirements will be misdirected and the resulting project will not represent 
the true need. 


Users will often begin describing their objectives in qualitative language. 
The project manager must work with the user to provide quantifiable 
definitions to those qualitative terms. These quantifiable criteria include: 
schedule, cost, and quality measures. In the case of project objectives, these 
elements are used as measurements to determine project satisfaction and 
successful completion. Subjective evaluations can be removed with actual 
numbers. 


Example: 

A web user may ask for a fast system. The quantitative example would be 
all screens must load in under 3 seconds. Describing the time limit in 
which the screen must load is specific and tangible. For that reason, you’ Il 
know that the requirement has been completed when the objective has been 
met. 


Example: 

Let’s say your company is going to produce a run of holiday eggnog. Your 
objective statement might be stated this way: Christmas Cheer, Inc. will 
produce two million cases of holiday eggnog to be shipped to our 
distributors by October 30 at a total cost of $1.5 million or less. The 
objective criteria in this statement are clearly stated and fulfillment of the 
project objective can be easily measured. Stakeholders will know the 
objective is met when the two million cases are produced and shipped by 
the due date within the budget stated. 


When articulating the project objectives you should follow the SMART 
rule: 


e Specific (get into the details). Objectives should be specific and 
written in clear, concise, and understandable terms. 

e Measurable (use qualitative language so you know when you are 
finished). A requirement must have a measurable outcome; otherwise 
you will not be able to determine when you have delivered it. 

e Acceptable (to stakeholders). 

e Realistic (in terms of achievement). Objectives that are impossible to 
accomplish are not realistic and not attainable. Objectives must be 
centered in reality. 

e Time bound (deadlines not durations). Objectives should have a 
timeframe with an end date assigned to them. 


If you follow these principles, you’ ll be certain that your objectives meet 
the quantifiable criteria needed to measure success. 


Scope planning 


You always want to know exactly what work has to be done to finish your 
project BEFORE you start it. You’ve got a collection of team members, and 
you need to know exactly what they’re going to do to build your product or 
meet the project’s objectives. The scope planning process if the very first 
thing you do to manage your scope. Project scope planning is concerned 
with defining all of the work of the project and only the work needed to 
successfully meet the project objectives. The whole idea here is that when 
you start the project, you need to have a clear picture of all the work that 
needs to happen on your project, and as the project progresses, you need to 
keep that scope up to date and written down in the project’s scope 
management plan. 


How do you define the scope? 


You already got a head start on refining the project’s objectives in 
quantifiable terms, but now you need to go a lot further and write down all 
of the deliverables that you and your team are going to produce over the 
course of the project. Deliverables include everything that you and your 
team produce for the project; anything that your project will deliver. The 
deliverables for your project include all of the products or services that you 
and your team are performing for the client, customer, or sponsor. But 
deliverables include more than that. They also include every single 
document, plan, schedule, budget, blueprint, and anything else that gets 
made along the way; including all of the project management documents 
you put together. Project deliverables are measurable outcomes, measurable 
results, or specific items that must be produced to consider the project or 
project phase completed. Deliverables like objectives must be specific and 
verifiable. 


All deliverables must be described in enough detail so that they can be 
differentiated from related deliverables. For example: 


e A twin engine plane versus a single engine plane. 
e A red marker versus a green marker. 


e A daily report versus a weekly report. 
e A departmental solution versus an enterprise solution. 


One of the project manager’s primary functions is to accurately document 
the deliverables and requirements of the project and then manage the 
project so that they are produced according to the agreed upon criteria. 
Deliverables describe the components of the goals and objectives in a 
quantifiable way. Requirements are the specifications of the deliverables. 


Project requirements 


After all the deliverables are identified, the project manager needs to 
discover and document all of the requirements of the project ((link]). 
Requirements describe the characteristics of the deliverable. They may also 
describe functionality that the deliverable must have or specific conditions 
the deliverable must meet in order to satisfy the objective of the project. A 
requirement is an objective that must be met. The project requirements 
defined in the scope plan describe what a project is supposed to accomplish 
and how the project is supposed to be created and implemented. 
Requirements answer the following questions regarding the AS IS and TO 
BE states of the business: who, what where, when, how much, how does a 
business process work. 


I CANT START THE START MAKING $0, OUR PLAN IS TO 
PROJECT BECAUSE THE CLEVERLY HIDE OUR 
USER WON'T GIVE ME “ 3 COMPETENCE. 


| 


HIS REQUIREMENTS. 


When you don’t get project requirements. Copyright: United 
Feature Syndicate, Inc. (2009). 


Requirements may include things like dimensions, ease of use, color, 
specific ingredients, and so on. If we go back to the example of the 
company producing holiday eggnog; one of the major deliverables is the 
cartons that hold the eggnog. The requirements for that deliverable may 
include carton design, photographs that will appear on the carton, color 
choices, etc. 


Requirements specify what the project deliverable should look like and 
what it should do. They can be divided into six basic categories, functional, 
non-functional, technical, user, business, and regulatory requirements. 


Functional requirements 


Functional requirements describe the characteristics of the deliverable, what 
emerges from the project in ordinary non-technical language. They should 
be understandable to the customers, and the customers should play a direct 
role in their development. Functional requirements are what you want the 
deliverable to do. 


Example: 

If you were buying vehicles for a business your functional requirement 
might be; the vehicle should be able to take a load from a warehouse to a 
shop. 


Example: 
For a computer system you may define what the system is to do; the system 
should store all details of a customer ’s order. 


The important point to note is that WHAT is wanted is specified, and not 
HOW it will be delivered. 


Non-functional requirements 


Non-functional requirements specify criteria that can be used to judge the 
product or service that your project delivers. They are restrictions or 
constraints to be placed on the deliverable and how to build it. Their 
purpose is to restrict the number of solutions that will meet a set of 
requirements. Using the vehicle example ([link]); without any constraints, 
the functional requirement of a vehicle to take a load from a warehouse to a 
shop, the solutions being offered might result in anything from a large truck 
to a sports car! Non-functional requirements can be split into two types: 
performance and development. 


To restrict the types of solutions you might include these performance 
constraints: 


e It must take a load of at least one ton. 
e The load area must be covered. 
e The load area must have a height of at least 10 feet. 


Similarly, for the computer system example ([link]), you might specify 
values for the generic types of performance constraints: 


e The response time for information to appear to a user. 

e The number of hours a system should be available. 

e The number of records a system should be able to hold. 

e The capacity for growth of the system. 

e The length of time a record should be held for auditing purposes. 


For the customer records example these might be: 


e The system should be available from 9 AM to 5 PM Monday to Friday. 
e The system should be able to hold 100,000 customer records initially. 

e The system should be able to add 10,000 records a year for 10 years. 

e A record should be fully available on the system for at least 7 years. 


The important point with these examples is that they restrict the number of 
solution options that are offered to you by the developer. In addition to the 
performance constraints you may include some development constraints. 


There are three general types of development constraints: 


e Time: When a deliverable should be delivered 

e Resource: How much money is available to develop the deliverable 

¢ Quality: Any standards that are used to develop the deliverable, and 
develop methods, etc. 


Technical requirements 


Technical requirements emerge from the functional requirements, they 
answer the question, and how will the problem be solved this time; will it 
be solved technologically and/or procedurally. They answer how the system 
needs to be designed and implemented to provide required functionality and 
fulfill required operational characteristics. For example, in a software 
project, the functional requirements may stipulate that a data base system 
will be developed to allow access to financial data through a remote 
terminal; the corresponding technical requirements would spell out the 
architecture of the data structure, the language in which the database 
management system will be written, the hardware on which the system will 
run, telecommunication protocols that should be used and so forth. 


User requirements 


User requirements are what the users need to do with the system or product. 
They focus on the experience users need to have with the system, they can 
also reflect how the product will be designed, and define how test cases 
must be formulated. 


Business requirements 


Business requirements are the needs of the sponsoring organization, always 
from a Management perspective. Business requirements are statements of 
the business rationale for the project. They are usually expressed in broad 
outcomes the business requires, rather than specific functions the system 
may perform. These requirements grow out of the vision for the product 
that, in turn, is driven by mission (or business) goals and objectives. 


Regulatory requirements 


Regulatory requirements can be internal or external and are usually non- 
negotiable. They are the restrictions, licenses and laws applicable to a 
product or business, imposed by the government. 


An example of requirements 


Automated teller machines (ATMs) can be used to illustrate a wide range of 
requirements ({link]). What are some of the physical features of these 
machines, and what kinds of functions do they perform for users? Why did 
banks put these systems in place? What high level business requirements 
did they have in mind? 


ATM 


24 HOUR BANKING 


A typical exterior 
automated teller 
machines (ATMs). 


The following represents one possible example of each type of requirement 
as they would be applied to a bank’s external ATM. 


e ATM function requirement: The system shall provide users with the 
ability to select whether or not to produce a hardcopy transaction 
receipt before completing a transaction. 

e ATM non-functional requirement: All displays shall be in white 14 
pt Arial text on black background. 

e ATM user requirement: The system shall complete a standard 
withdrawal from a personal account, from login to cash, in less than 
two minutes for a first time user. 

e ATM business requirement: By providing superior service to our 
retail customers, Monumental Bank’s ATM network will allow us to 
increase associated service fee revenue by 10% annually on an 
ongoing basis, using a baseline of December 2008. 

e ATM regulatory requirement: All ATMs shall connect to standard 
utility power sources within their civic jurisdiction, and be supplied 


with uninterruptible power source approved by said company. 


The effective specification of requirements is one of the most challenging 
undertakings project managers face. Inadequately specified requirements 
will guarantee poor project results. 


Documenting requirements is much more than just the process of writing 
down the requirements as the user sees them; it should cover not only what 
decisions have been made but also why they have been made. 
Understanding the reasoning that used to arrive at a decision is critical in 
avoiding repetition. For example, if a particular feature has been excluded 
because it is simply not feasible, that fact needs to be recorded. If it is not, 
then the project risks wasted work and repetition when a stakeholder 
requests the feature be reinstated during development or testing. Once the 
requirements are documented, have the stakeholders sign off on their 
requirements as a confirmation of what they desire. 


While the project manager is responsible for making certain the 
requirements are documented, it does not mean the project manager must 
perform this task. The project manager can enlist the help of stakeholders, 
business analysts, requirement analysts, business process owners, and other 
team members to conduct the interviews and document the requirements. 
The project manager then reviews the requirements and incorporates them 
into the project documentation and project plan. 


Preparing the work breakdown structure 


Now that we have the deliverables and requirements well defined, the 
process of breaking down the work of the project via a work breakdown 
structure begins. The work breakdown structure (WBS) defines the scope of 
the project and breaks the work down into components that can be 
scheduled and estimated and easily monitored and controlled. The idea 
behind the work breakdown schedule is simple. You subdivide a 
complicated task into smaller tasks, until you reach a level that cannot be 
further subdivided. Anyone familiar with the arrangements of folders and 
files in a computer memory, or who has researched their ancestral family 
free, should be familiar with this idea. You stop breaking down the work 


when you reach a low enough level to perform an estimate of the desired 
accuracy. At that point, it is usually easier to estimate how long the small 
task will take and how much it will cost to perform than it would have been 
to estimate these factors at the higher levels. Each descending level of the 
WBS represents an increased level of detailed definition of the project 
work. 


As an example, if I want to clean a room, I might begin by picking up 
clothes, toys, and other things that have been dropped on the floor. I could 
use a vacuum cleaner to get dirt out of the carpet. I might take down the 
curtains and take them to the cleaners, then dust the furniture. All of these 
tasks are subtasks performed to clean the room. As for vacuuming the 
room, I might have to get the vacuum cleaner out of the closet, connect the 
hose, empty the bag, and put the machine back in the closet. These are 
smaller tasks to be performed in accomplishing the subtask called 
vacuuming. The diagram in [link] shows how this might be portrayed in 
WBS format. 


0.0 Clean Room 
oe) aii 


1.0 Mop floor 


Ly! 1.1 Get mop and 
bucket out 


2.0 Dust 


2.1 Coffe table 


4.0 Clean curtains 


3.1 Get vacuum out of 


4.1 Remove curtains 
closet 


L»| 1.2 Mix cleaner with 
water in bucket 


2.2 Blinds 


>| 3.2 Vacuum carpet 


4.1 Toys 
4.1.1 Put toys in 
box 


4.2 Take to cleaners 


1.3 Rinse out bucket 
and mop 


7 3.3 Empty bag 
3.4 Connect hose and 
plug 


4.2 Clothes 


4.2.1 hang up in 
closet 


Hr 


4.3 Hang curtains 


A work breakdown structure (WBS) for cleaning a room. 


It is very important to note that we do not worry about the sequence in 
which the work is performed or any dependencies between them when we 


do a WBS. That will be worked out when we develop the schedule. For 
example, under 3.0 Vacuum (in [link]), it would be obvious that 3.3 Vacuum 
carpet would be performed after 3.4 Connect hose and plug! However, you 
will probably find yourself thinking sequentially, as it seems to be human 
nature to do so. The main idea of creating a WBS is to capture all of the 
tasks, irrespective of their order. So if you find yourself and other members 
of your team thinking sequentially, don’t be too concerned, but don’t get 
hung up on trying to diagram the sequence or you will slow down the 
process of task identification. 


A WBS can be structured any way it makes sense to you and your project. 
In practice, the chart structure is used quite often (as in the example in 
[link]) but it can be composed in outline form as well ({link]). 


Cleaw Roow 
1.0 Mop Floor » 
1.1 Get mop out of closet 
1.2 Mix cleaner with water iw 


1.3 Rinse out bucket and Mop 
2.0 Dust 
2.1 Coffee Table 
2.2 Blinds 
3.0 Vacuum 
3.1 Get vacuum out of closet . 
3.2 Vacuum corpet 
3.3 Empty bag 
3.4 COS CE Uae CI DUSg. 
4.0 Pick Up Floor 
4.1 Toyy 
4.1.1 Duttoc iu toy bow 
oa? Clothey — 
4.2.1 Hang up in closet 
5.0 Cleaw Curtainy 
5.1 Remove Curtainy 
_ 5.2 Take to Cleanery 
5.3 Hang Curtainy 


An outline format of a 
work breakdown structure 
(WBS) for cleaning a 
room. 


You’ll notice that each element at each level of the WBS (in either [link] or 
[link]) is assigned a unique identifier. This unique identifier is typically a 
number, and it’s used to sum and track costs, schedules, and resources 
associated with WBS elements. These numbers are usually associated with 
the corporation’s chart of accounts, which is used to track costs by category. 
Collectively, these numeric identifiers are known as the code of accounts. 


There are also many ways you can organize the WBS. For example, it can 
be organized by either deliverable or phase. The major deliverables of the 
project are used as the first level in the WBS. For example, if you are doing 
a multimedia project the deliverables might include producing a book, CD 
and a DVD ([(link)). 


0.0 Multimedia Project 


1.0 Book 


>| 1.1 Writing 2.1 Writing 3.1 Writing 
[>] 1.2 Publishing 2.2 Recording 3.2 Recording 
t>| 1.3 Producing 2.3 Producing 3.3 Producing 


1.4.1 Retail 2.4.1 Retail 3.4.1 Retail 
1.4.2 Mail 2.4.2 Mail 3.4.2 Mail 


An example of a work breakdown structure (WBS) 
based on project deliverable. 


2.4 Selling 


Many projects are structured or organized by project phases. Each phase 
would represent the first level of the WBS and their deliverables would be 
the next level and so on ({link]). 


0.0 Project XXX 
u 
1.0 Phase 1 2.0 Phase 2 3.0 Phase 3 


[>| 1.1 Process requirements [>| 3.1 Location 
1.2.1 Identify all data entries +} 2.3 People 
1.2.2 Load data modeling tool 


| 1.3 Conceptual design 


b>] 


> ww. 
[>| 2.3.2 Part time [>| 3.2 Surveys 
| 2.3.3 Temporary >| 3.3 New designs 


An example of a work breakdown structure (WBS) 
based on project phase. 


As mentioned earlier, the project manager is free to determine the number 
of levels in the WBS based on the complexity of the project. You need to 
include enough levels to accurately estimate project time and costs but not 
so many levels that are difficult to distinguish between components. 
Regardless of the number of levels in a WBS, the lowest level in a WBS is 
called a work package. 


Work packages are the components that can be easily assigned to one 
person, or team of people, with clear accountability and responsibility for 
completing the assignment. The work package level is where time 
estimates, costs estimates and resource estimates are determined. 


Project schedule development 


Now were off and running toward the development of our project schedule. 
In order to develop our schedule, we first need to define the activities, 
sequence them in the right order, estimate resources and estimate the time it 
will take to complete the tasks. 


The activity definition process is a further breakdown of the work package 
elements of the WBS. It documents the specific activities needed to fulfill 
the deliverable detailed in the WBS. These are not deliverables but the 
individual units of work that must be completed to fulfill the deliverables. 
Activity definition uses everything we already know about the project to 
divide the work into activities that can be estimated. You might want to 
look at all the lessons learned from similar projects your company has done 
to get a god idea of what you need to do on the current one. 


Expert judgment in the form of project team members with prior experience 
developing project scope statements and WBS can help you define 
activities. You might also use experts in a particular field to help define 
tasks if you were asked to manage a project in a new domain; to help you 
understand what activities were going to be involved. It could be that you 
create an activity list and then have the expert review it and suggest 
changes. Alternatively, you could involve the expert from the very 
beginning and ask to have an activity definition conversation with him 
before even making your first draft of the list. 


Sometimes you start a project without knowing a lot about the work that 
you’ ll be doing later. Rolling wave planning lets you plan and schedule only 
the stuff that you know enough about to plan well. When you don’t know 
enough about a project to come up with a complete activity list, you can use 
a planning component as a placeholder until you know more. These are 
extra items put at high levels in the WBS to allow you to plan for the 
unknown. 


A case study 


Susan and Steve have decided to tie the knot, but they don’t have much 
time to plan their wedding. They want the big day to be unforgettable. They 
want to invite a lot of people and show them all a great time. They’ve 
always dreamed of a June wedding, but it’s already January. Just thinking 
about all of the details involved is overwhelming. Somewhere around 
picking the paper for the invitations, the couple realizes they need help. 


Susan’s been dreaming of the big day since she was 12, but it seems like 
there’s so little time to do it all. 


Steve, we need some help. 


Don’t worry. My sister’s wedding planner was great. Let me give her a call. 


So saying Steve calls the wedding planner Sally. 


We want everything to be perfect. 


There is so much to do! Invitations, food, guests, and music. 


Oh no, we haven’t even booked a place! 


And it’s got to be done right. We can’t print the initiations until we have the 
menu planned. We can’t do the seating arrangements until we have the 
RSVPs. We aren’t sure what kind of band to get for the reception, or should 
it be a DJ? We’re just overwhelmed. 


My sister said you really saved her wedding. I know she gave you over a 
year to plan. 


But I’ve always dreamed of a June wedding, and I’m not willing to give 
that up. I know it’s late, but Sally can you help us? 


Take it easy guys. I’ve got it under control. We’ve got a lot of people and 
activities to get under control. You guys really should have called six 
months ago, but we’|l still make this wedding happen on time. 


There’s a lot to get done before June. Sally’s going to need to figure out 
what work needs to done before she does anything else. For this she starts 
to put together a to-do-list. 


e Invitations 

e Flowers 

¢ Wedding Cake 
e Dinner Menu 
e Band 


Since there are so many different people involved in making the wedding 
go smoothly, it takes a lot of planning to make sure all of the work happens 
in the right order, gets done by the right people and doesn’t take too long. 
Initially, Sally was worried that she didn’t have enough time to make sure 
everything was done properly. But she knew that she had some powerful 
time management tools on her side when she took the job, and they’ Il help 
her make sure that everything will work out fine. 


To get started, Sally started arranging the activities in a work breakdown 
structure. This is part of the WBS Sally made for the wedding. 
Exercise: 


Problem: 


Arrange the following activities into the WBS to show how the work 
items decompose into activities. 


e Shop for shoes 

e Create guest list 

e Tailoring and fitting 
e Shop for dress 

e Find caterer 

e Cater the wedding 

e Wait for RSVPs 

e Mail the invitations 
e Finalize the menu 

e Print the invitations 
e Choose the bouquet 


0.0 Wedding 
2.0 Food 


= 


Solution: 


1.0 Invitations 3.0 Bridal 


0.0 Wedding 


1.0 Invitations 2.0 Food 


3.0 Bridal 


3.1 Shop for dress 
3.2 Shop for shoes 


3.3 Choose bouquet 


1.1 Create guest list 2.1 Find caterer 


1.2 Print the invitations DPinalizeimentl 


1.3 Mail the invitations 2.3 Cater wedding 


1.4 Wait for RSVPs 


3.4 Tailoring and fitting 


Activity definition 


Now that the activity definitions for the work packages have been 
completed, the next task is to complete the activity list. The project activity 
list is a list of everything that needs to be done to complete your project, 
including all the activities that must be accomplished to deliver the work 


package. Next you want to define the activity attributes. Here’s where the 
description of each activity is kept. All of the information you need to 
figure out; the order of the work should be here too. So any predecessor 
activities, successor activities or constraints should be listed in the attributes 
along with descriptions and any other information about resources or time 
that you need for planning. The three main kinds of predecessors are finish- 
to-start (FS), start-to-start (SS) and finish-to-finish (FF). 


The most common kind of predecessor is the finish-to-start. It means that 
one task needs to be completed before another one can start. When you 
think of predecessors, this is what you usually think of, one thing needs to 
end before the next can begin. It’s called finish-to-start because the first 
activity finish leads into the second activity’s start ({link]). 


Print invitations 


An example of a finish-to-start (FS) 
predecessor. 


The start-to-start predecessor is a little less common, but sometimes you 
need to coordinate activities so they begin at the same time ([link]). 


Serve cake 


An example of a 


Start-to-start (SS) 
predecessor. 


In the finish-to-finish predecessor it shows activities that finish at the same 
time ([link]). 


Play "Here comes 
the bride" 


Bride walks down 
the isle 


An example of a 
finish-to-finish 
(FF) predecessor. 


It is possible to have to have start-to-finish (SF) predecessors. This happens 
when activities require that a task be started before it can finish. An 
example might be that singing couldn’t start until after the music had 
started. Keep in mind that tasks like that are pretty rare and almost never 
show up in network diagrams. In addition there are some particular types of 
predecessors that must be considered. 


External predecessors 


Sometimes your project will depend on things outside the work your doing. 
For the wedding, we are depending on the wedding party before us to be out 
of the reception hall in time for us to decorate. The decoration of the 
reception hall then depends on that as an external predecessor. 


Discretionary predecessors 


These are usually process or procedure driven or "best practice" techniques 
based on past experience. Using the wedding example: Steve and Susan 
really want the bridesmaids to arrive at the reception before the couple. 
There’s no necessity there- it’s just a matter of preference. 


Mandatory predecessors 


You can’t address an invitation that hasn’t been printed yet. So, printing 
invitations is a mandatory predecessor for addressing them. Mandatory 
predecessors are the kinds that have to exist just because of the nature of the 
work. 


Leads and lags 


Sometimes you need to give some extra time between activities. Lag time is 
when you purposefully put a delay between the predecessor task and the 
successor. For example, when the bride and her father dance, everybody 
waits a while before they join them ([Link]). 


Bride and father dance 


Everyone else dances 


A lag means 
making sure that 
one task waits a 

while before it gets 
started. 


Lead time is when you give a successor task some time to get started before 
the predecessor finishes ((link]). So you might want the caterer preparing 
dessert an hour before everybody is eating dinner. 


Prepare dessert 


A lead is when you 
let a task get started 
before its 
predecessor is 
done. 


Milestones 


All of the important checkpoints of your project are tracked as milestones. 
Some of them could be listed in your contract as requirements of successful 
completion; some could just be significant points in the project that you 
want to keep track of. The milestone list needs to let everyone know which 
are required and which are not. 


Some milestones for Susan and Steve’s wedding might be: 


e Invitations sent 


e Menu finalized 
e Location booked 
e Bridesmaids’ dresses fitted 


As you figure out which activities will need to be done, you may realize 
that the scope needs to change. When that happens, you need to create a 
change request and send it through the change control system. So back to 
our couple and their nuptial plan. 


We just got the programs back from the printer and they’re all wrong. 


The quartet cancelled. They had another wedding that day. 


Aunt Jane is supposed to sing at the service, but after what happened at her 
uncle’s funeral, I think I want someone else to do it. 


Should we really have a pan flute player? I’m beginning to think it might be 
overkill. 


Apparently! Maybe we should hold off printing the invitations until this 
stuff is worked out. 


OK, let’s think about exactly how we want to do this. I think we need to be 
sure about how we want the service to go before we do any more printing. 


The activity sequencing process 


Now that we know what we have to do to make the wedding a success, we 
need to focus on the order of the work. Sally sat down with all of the 
activities she had defined for the wedding and decided to figure out exactly 
how they needed to happen. That’s where she used the activity sequencing 
process. 


The activity attribute list Sally created had most of the predecessors and 
successors necessary written in it. This is where she thought of what comes 
first, second, third, etc. Sally’s milestone list had major pieces of work 
written down and there were a couple of changes to the scope she had 
discovered along the way that were approved and ready to go. 


Example: 

Milestone list: Steve and Susan had asked that the invitations be printed at 
least three months in advance to be sure that everyone had time to RSVP. 
That’s a milestone on Sally’s list. 


Example: 

Change request: When Sally realized that Steve and Susan were going to 
need another limo to take the bridesmaids to the reception hall, she put that 
change through change control- including running everything by Susan’s 
mother- and it was approved. 


Creating the network diagram 


The first step in developing the schedule is to develop a network diagram of 
the WBS work packages. The network diagram is a way to visualize the 
interrelationships of project activities. Network diagrams provide a 
graphical view of the tasks and how they relate to one another. The tasks in 
the network are the work packages of the WBS. All of the WBS tasks must 
be included in the network because they have to be accounted for in the 
schedule. Leaving even one task out of the network could change the 
overall schedule duration, estimated costs and resource allocation 
commitments. 


The first step is to arrange the tasks from your WBS into a sequence 
({link]). Some tasks can be accomplished at any time throughout the project 
where other tasks depend on input from another task or are constrained by 
time or resources. 


The relationship between the work breakdown structure (WBS) 
and the network diagram. 


The WBS is not a schedule, but it is the basis for it; the network diagram is 
a schedule but is used primarily to identify key scheduling information that 
ultimately goes into user friendly schedule formats, such as milestone and 
Gantt charts. 


The network diagram provides important information to the project team. It 
provides information about how the tasks are related ({link]), where the risk 
points are in the schedule, how long it will take as currently planned to 
finish the project, and when each task needs to begin and end. 


In our wedding planner example, Sally would look for relationships 
between tasks and determined what can be done in parallel and what 
activities needed to wait for others to complete. As an example, [link] 
shows how the activities involved in producing the invitations depend on 


one another. Showing the activities in rectangles and their relationships as 
arrows is called a precedence diagramming method (PDM). This kind of 
diagram is also called an activity on node (AON) diagram. 


This arrow shows a finish-to-start predecessor 
between the “pick calligrapher” and “address 


invitations” activities 
Pick Address Send 
calligrapher invitations invitations 
The successor to "print 


invitations" is “address 
invitations" 


Design Print 
invitations invitations 


"Printing invitations" 
depends on designing 
invitations" 


"Pick calligrapher" 
and "pick printer" 
have no 
predecessors 


Pick printer 


An example of an activity on node (AON) diagram. 


Another way to show how tasks relate is with the activity-on-arrow (AOA). 
Although activity-on-node (AON) is more commonly used and is supported 
by all project management programs, PERT is the best-known AOA-type 
diagram and is the historical basis of all network diagramming. The main 
difference is the AOA diagram is traditionally drawn using circles as the 
nodes, with nodes representing the beginning and ending points of the 
arrows or tasks. In the AOA network, the arrows represent the activities or 
tasks ({link]). 


An example of an activity-on-arrow (AOA) 
network diagram. 


All network diagrams have the advantages as showing task 
interdependencies, start and end times, and the critical path (the longest 
path through the network) but the AOA network also has some 
disadvantages that limit the use of the method. 


The three major disadvantages of the AOA method are: 


e The AOA network can only show finish to start relationships. It is not 
possible to show lead and lag except by adding or subtracting time, 
which makes project tracking difficult. 

e There are instances when dummy activities can occur in an AOA 
network. Dummy activities are activities that show the dependency of 
one task on other tasks but for other than technical reasons. For 
example, a task may be dependent on another because it would be 
more cost effective to use the same resources for the two; otherwise 
the two tasks could be accomplished in parallel. Dummy activities do 
not have durations associated with them. They simply show that a task 
has some kind of dependence on another task. 

e AOA diagrams are not as widely used as AON simply because the 
latter are somewhat simpler to use and all project management 


software programs can accommodate AON networks, whereas not all 
can accommodate AOA networks. 


Resource planning 


In our case study it is clear that Steve and Susan have resource problems. 
Getting a handle on all of the tasks that have to be done is a great start, but 
it’s not enough to know the tasks and the order they come in. Before you 
can put the final schedule together, you need to know who is going to each 
job, and the things they need available to them in order to do it! 


We’ve got so much to do! Invitations, catering, music... and I’ve got no idea 
who’s going to do it all. I’m totally overwhelmed. 


From this statement it is clear that Susan is worried about human resources. 
In comparison, Steve realizes that not all resources are people! 


And it’s not just people! We need food, flowers, a cake, a sound system, and 
a venue! How do we get a handle on this? 


Resources are people, equipment, locations, or anything else that you need 
in order to do all of the activities that you planned for. Every activity in 
your activity list needs to have resources assigned to it. Before you can 
assign resources to your project, you need to know which ones you’re 
authorized to use; that’s called resource availability. Resource availability 
includes information about what resources you can use on your project and 
when they’re available to you. Don’t forget that some resources like 


consultants or training rooms have to be scheduled in advance, and they 
might only be available at certain times. You’!] need to know this before 
you can finish planning your project. If you are starting to plan in January, a 
June wedding is harder to plan than one in December, because the wedding 
halls are all booked up in advance. That is clearly a resource constraint. 
You’ll also need the activity list that you created earlier, and you’!l need to 
know about how your organization typically handles resources. Once 
you’ve got a handle on these things, you’re set for resource estimation. 


Estimating the resources 


The goal of activity resource estimating is to assign resources to each 
activity in the activity list. There are five tools and techniques for the 
activity resource estimating process. Some of them have technical sounding 
names, but they’re all actually pretty sensible when you think about it. They 
should make sense to you when you think about what you have to do when 
you have to figure out what resources your project needs. 


e Expert judgment means bringing in experts who have done this sort 
of work before and getting their opinions on what resources are needed 
({link]). 

e Alternative analysis means considering several different options for 
how you assign resources. This includes varying the number of 
resources as well as the kind of resources you use. Many times, there’s 
more than one way to accomplish an activity and alternative analysis 
helps decide among the possibilities. 

¢ Published estimating data is something that project managers in a lot 
of industries use to help them figure out how many resources they 
need. They rely on articles, books, journals, and periodicals that 
collect, analyze, and publish data from other people’s projects. 

¢ Project management software such as Microsoft project will often 
have features designed to help project managers estimate resource 
needs and constraints and find the best combination of assignments for 
the project. 

e Bottom-up estimating means breaking down complex activities into 
pieces and working out the resource assignments for each piece. It is a 


process of estimating these individual activities or costs and then 
adding these up together to come up with a total estimate. Here you 
estimate every scheduled activity individually and then roll up that 
estimate; or add them all together, to come up with a total. Bottom-up 
estimating is a very accurate means of estimating, provided the 
estimates at the schedule activity level are accurate. However, it takes 
a considerable amount of time to perform bottom-up estimating 
because every activity must be accessed and estimated accurately to be 
included in the bottom-up calculation. The smaller and more detailed 
the activity, the greater the accuracy and cost of this technique. 
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In each of the following scenarios for planning Steve and Susan’s wedding 
determine which of the five activity resource estimation tools and 
techniques is being used. 


Exercise: 
Problem: 


Sally has to figure out what to do for the music at Steve and Susan’s 
wedding. She considers using a DJ, a rock band, or a string quartet. 


Solution: 


Alternative analysis. 
Exercise: 
Problem: 
The latest issue of Wedding Planner’s Journal has an article on 


working with caterers. It includes a table that shows how many waiters 
work with varied guest-list sizes. 


Solution: 


Published estimating data. 
Exercise: 
Problem: 
There’s a national wedding consultant who specializes in Caribbean 


themed weddings. Sally gets in touch with her to ask about menu 
options. 


Solution: 


Expert judgment. 
Exercise: 
Problem: 


Sally downloads and fills out a specialized spreadsheet that a project 
manager developed to help with wedding planning. 


Solution: 


Project management software. 

Exercise: 
Problem: 
There’s so much work that has to be done to set up the reception hall 
that Sally has to break it down into five different activities in order to 
assign jobs. 


Solution: 


Bottom-up estimating 
Exercise: 


Problem: 


Sally asks Steve and Susan to visit several different caterers and 
sample various potential items for the menu. 


Solution: 


Alternative analysis 
Exercise: 


Problem: 


Sally calls up her friend who knows specifics of the various venues in 
their area for advice on which one would work best. 


Solution: 


Expert judgment. 


Estimating activity durations 


Once you’re done with activity resource estimating, you’ve got everything 
you need to figure out how long each activity will take. That’s done ina 
process called activity duration estimating. This is where you look at each 
activity in the activity list, consider the scope and the resources and 
estimate how long it will take to perform. 


Estimating the duration of an activity means starting with the information 
you have about that activity and the resources that are assigned to it, and 
then working with the project team to come up with an estimate. Most of 
the time you’ll start with a rough estimate and then refine it to make it more 
accurate. You’ll use these five tools and techniques to create the most 
accurate estimates: 


e Expert judgment will come from your project team members who are 
familiar with the work that has to be done. If you don’t get their 
opinion, then there’s a huge risk that your estimates will be wrong. 

e Analogous estimating is when you look at activities from previous 
projects that were similar to this one and look at how long it took to do 
similar work before. But this only works if the activities and the 
project team are similar! 

e¢ Parametric estimating means plugging data about your project into a 
formula, spreadsheet, database, or computer program that comes up 
with an estimate. The software or formula that you use for parametric 
estimating is built on a database of actual durations from past projects. 

e Three-point estimates are when you come up with three numbers: a 
realistic estimate that’s most likely to occur, an optimistic one that 
represents the best-case scenario, and a pessimistic one that represents 
the worst-case scenario. The final estimate is the average. 

e Reserve analysis means adding extra time to the schedule (called a 
contingency reserve or a buffer) to account for extra risk. 


In each of the following scenarios for planning Steve and Susan’s wedding 
determine which of the five activity duration estimation tools and 
techniques is being used. 

Exercise: 


Problem: 


Sally comes up with three estimates (one where everything goes 
wrong, one where some things go wrong, and one where nothing goes 
wrong) for printing invitations, and average them together to come up 
with a final number. 


Solution: 


Three-point estimate. 
Exercise: 
Problem: 
Sally comes up with three estimates (one where everything goes 
wrong, one where some things go wrong, and one where nothing goes 


wrong) for printing invitations, and averages them together to come up 
with a final number. 


Solution: 


Three-point estimate. 
Exercise: 
Problem: 
There are two different catering companies at the wedding. Sally asks 


the head chef at each of them to give her an estimate of how long it 
will take each of them to do the job. 


Solution: 


Expert judgment. 


Exercise: 


Problem: 


There’s a spreadsheet Sally always uses to figure out how long it takes 
guest to RSVP. She enters the number of guests and their zip codes, 
and it calculates estimates for her. 


Solution: 


Parametric estimating. 
Exercise: 


Problem: 


Sally’s done four weddings that are very similar to Steve and Susan’s, 
and in all four of them it took exactly the same amount of time for the 
caterers to set up the reception hall. 


Solution: 


Analogous estimating. 


You’ve got a list of activities, you know what resources are needed to 
actually do each activity, and you’ve got your estimation tools and 
techniques, now you have enough information to create the estimate! The 
activity duration estimates are an estimate of how long each activity in the 
activity list will take. This is a quantitative measure usually expressed in 
hours, weeks, days, or months. Any work period is fine, and you’Il use 
different work periods for different jobs. A small job (like booking a DJ) 
may just take a few hours; a bigger job (like catering-including deciding on 
a menu, ordering ingredients, cook food and serving guests on the big day) 
could take days. 


Another thing to keep in mind when estimating the duration of the 
activities, is determining the effort involved. Duration is the amount of the 
time that an activity takes, while effort if the total number of person-hours 
that are expended. If it takes two people six hours to carve the ice sculpture 
for the centerpiece of a wedding, the duration is six hours. But if two people 


worked on it for the whole time, it took twelve person-hours of effort to 
create! 


You’ll also learn more about the specific activities while you’re estimating 
them. That’s something that always happens. You have to really think 
through all of the aspects of a task in order to estimate it. As you learn more 
about the specific activities remember to update the activity attributes. 


If we go back to our case study of the wedding we can see that while Sally 
has got a handle on how long things are going to take, that’s not enough to 
get the job done. She still has some work to do before she’s got the whole 
project under control. Steve and Susan know where they want to get 
married, and they’ve got the place booked now, but what about the caterer? 
They have no idea who’s going to be providing food. And what about the 
band they want? Will the timing with their schedule work out? 


If the caterers come too early, the food will sit around under heat lamps! 
But, if they come too late, then the band won’t have time to play. I just 
don’t see how we’|l ever work this out! 


It’s not easy to plan for a lot of resources when they have tight time 
restrictions and overlapping constraints. How do you figure out a schedule 
that makes everything fit together? You’re never going to have the complete 
resource picture until your done building the schedule. And the same goes 
for your activity list and duration estimates too! It’s only when you lay out 
the schedule that you’ll figure out that some of your activities and durations 
didn’t quite work. 


Project schedule 


The project schedule should be approved and signed off by stakeholders 
and functional managers. This assures they have read the schedule, 
understand the dates and resource commitments, and will likely cooperate. 
You’|l also need to obtain confirmation that will be available as outlined in 
the schedule. The schedule cannot be finalized until you receive approval 
and commitment for the resource assignments outlined in it. 


Once the schedule is approved, it will become your baseline for the 
remainder of the project. Project progress and task completion will be 
monitored and tracked against the project schedule to determine if the 
project is on course as planned. 


The schedule can be displayed in a variety of ways, some of which are 
variations of what you have already seen. Project schedule network 
diagrams will work as schedule diagrams when you add the start and finish 
dates to each activity. These diagrams usually show the activity 
dependencies and critical path. 


The critical path method is an important tool for keeping your projects on 
track. Every network diagram has something that is called the critical path. 
It’s the string of activities that, if you add up all of the durations, is longer 
than any other path through the network. It usually starts with the first 
activity in the network and usually ends with the last one. 


Aunt Jane is a vegetarian. That won’t be a problem, right? 


Well, let’s see. What menu did we give the caterers? 


We didn’t give it to them yet; because we won’t have the final menu until 
everyone RSVPs and lets us know which entrée they want. 


But they can’t RSVP because we haven’t sent out the invitations! What’s 
holding that up? 


We’re still waiting to get them back from the printer. We can’t send them 
out if we don’t have them yet! 


Oh no! I still have to tell the printer what to print on the invitations, and 
what paper to use. 


But you were waiting on that until we finished the guest list. 


What a mess! 


Steve thought Aunt Jane being a vegetarian was just a little problem. But it 
turns out to be a lot bigger than either Steve or Susan realized at first! 
How’d a question about one guest’s meal lead to such a huge mess? 


The reason that the critical path is critical is that every single activity on the 
path must finish on time in order for the project to come in on time. A delay 
in any one of the critical path activities will cause the entire project to be 
delayed ([link]). 


A delay here... 


Create Print the Mail the Wait for Finalize the Cater the 
guest list invitaions invitations RSVPs menu wedding 


will cause 
problems here! 


An example of problems that can be caused within the critical path. 


Knowing where your critical path is can give you a lot of freedom. If you 
know an activity is not on the critical path, then you know a delay in that 
activity may not necessarily delay the project. This can really help you 
handle emergency situations. Even better, it means that if you need to bring 
your project in earlier than was originally planned, you know that by adding 
resources to the critical path will be much more effective than adding them 
elsewhere. 


It’s easy to find the critical path in any project! Of course, on a large project 
with dozens or hundreds of tasks, you’!l probably use software like 


Microsoft Project to find the critical path for you. But when it does, it’s 
following the same exact steps that are followed here. 


Start with a network A You'll usually write 


the duration above 


1 each node in the 
diagram. care 
8 Activity "A" Activity "C diagram 
Look for paths by 
starting here and 7 
moving to the right 
Activity "B" 
Each time you 
see a branch in 3 5 
the actual Two branches means 
diagram that Activity "D" Activity "E" two additional paths 
means you've 
found another 
path 
Find all the paths in the 


diagram. A path is any 
string of activities that goes 
from the start of the project 
to the end. 


Find the duration of each “ 

path by adding up the 

durations of each of the 

activities on the path. 

The first path has a duration of 11, which is longer than the other paths, so 
it’s the critical path! 


The schedule can also be displayed using a Gantt chart ({link]). Gantt 
charts are easy to read and commonly used to display schedule activities. 
Depending on the software you use to display the Gantt chart, it might also 
show activity sequences, activity start and end dates, resource assignments, 
activity dependencies, and the critical path. Gantt charts are also known as 
bar charts. 


Design Server database structure 2days Sat 4701 Sun 4/8/01 i, Gita Tripathi: 
Implement Database Module 6 days Mon 4/9/01 Sat 44101 j ¢ 
Implement Database Utility Module 4days Sun 45/01) Wed 418/01 
Implement SuperUserManager Module 2days) Thu 49/01 Fri 4/20/01 
Implement lO modules: 7 days Sun 4/8/01 Sat 414101 
Research RMILite and Ninja | 4days) Sun 45/01) Wed 446/01 
Design Palm database structure 1O0days) Thu 49/01 Sat 4/28/01 
2days) Mon 4/9/01 = Tue 40/01 
Implement Meeting Manager Module 2days Wed41/01 9 Thu 412/01 
Implement Open Meeting Monitor module 3 days Fri4301 = Sun 45/01 
Implement Schedule Module Sdays Wed 4/18/01 Fri 4/20/01 
Implement Composite Schedule Module 4 days. Sat 4/2101 Tue 4/24/01 
Implement Authentication Manager Module 1 day. Thu 4/26/01 = Thu 4/26/01 
Implement Log Manager Module | 1day Fri 4/27/01 Fri 4/27/01 
Research OSKI 1 day Sat 4/7/01 Sat 4/7101 
Implement User Synchronization Module S days Sun 4/8/01 Mon 4/16/01 
Implement Server Synchronization Module Sdays Wed4"8/01 = Thu 4/26/01 


Implement PalmOS GUI screen modules Sdays Sat 4701 = Sun 445/01 
Implement Client Rendezvous Application Module 4days) Thu49901 9 Sun 4/22/01 
Implement Ul Manager Module Sdays Mon 4/23/01 Wed 4/25/01 


Design Intergration Tests ra days. Tue 4/24/01 = Mon 4/30/01 
Intergration Testing - Fdays Tue SMi01 Mon 5/7/01 
Blackbox Testing 3 days Tue 5/8/01 Thu 510/01 
User Testing 1 day Fri 5/1101 Fri 511/01 
User Manual 1day Sat52/01 Sat 52/01 


Presentation Preperation dday Mon54901 Mon 54/01 


An example of a Gantt chart. 


Budget Planning 


Every project boils down to money. If you had a bigger budget, you could 
probably get more people to do your project more quickly and deliver more. 
That’s why no project plan is complete until you come up with a budget 
({link]). But no matter whether your project is big or small, and no matter 
how many resources and activities are in it, the process for figuring out the 
bottom line is always the same. 


NAME QNE THING THAT 
EVERYONE WOULD AGREE 
IS A LOW PRIORITY. 


WHAT IS THE 

PRIORITY OF 
YOUR BUDGET 
REQUEST? 


EVERYONE RATED 
THEIR OWN BUDGET 
NEEDS “HIGHEST 
PRIORITY. IT IS 
A MOCKERY OF THE 
PRIORITY SYSTEM! 


WHATEVER 
YOU'RE DOING. 


HIGHEST 


Zlrslo3 ©2003 United Feature Syndicate, Inc 


www.dilbertcom scottadams@aolcom 


Defining the priority of a budget! Copyright: United Features 
Syndicate, Inc. (2003). 


It is important to come up with detailed estimates of all the project costs. 
Once this is obtained, add up the cost estimates into a budget plan. It is now 
possible to track the project according to that budget while the work is 
ongoing. 


A lot of times you come into a project and there is already an expectation of 
how much it will cost or how much time it will take. When you make an 
estimate really early in the project and you don’t know much about it, that 
estimate is called a rough order of magnitude estimate (or a ballpark 
estimate). It’s expected that this estimate will become more refined as time 
goes on and you learn more about the project. Here are some more tools and 
techniques used to estimate cost: 


e Determine resource cost rates: People who will be working on the 
project all work at a specific rate. Any materials you will use to build 
the project (like wood or wiring) will be charged at a rate too. This just 
means figuring out what the rate for labor and materials will be. 

e Vendor bid analysis: Sometimes you will need to work with an 
external contractor to get your project done. You might even have 
more than one contractor bid on the job. This tool is all about 
evaluating those bids and choosing the one you will go with. 

e Reserve analysis: You need to set aside some money for cost 
overruns. If you know that your project has a risk of something 


expensive happening, better to have some cash lying around to deal 
with it. Reserve analysis means putting some cash away just in case. 

¢ Cost of quality: You will need to figure the cost of all your quality 
related activities into the overall budget, too. Since it’s cheaper to find 
bugs earlier in the project than later, there are always quality costs 
associated with everything your project produces. Cost of quality is 
just a way of tracking the cost of those activities and is how much 
money it takes to do the project right. 


Once you apply all the tools in this process, you will arrive at an estimate 
for how much your project will cost. It’s always important to keep all of 
your supporting estimate information, too. That way, you know the 
assumptions you made when you were coming up with your numbers. Now 
you are ready to build your budget plan. 


Procurement planning 


Procurement management follows a logical order. First, you plan what you 
need to contract; then you plan how you’! do it. Next, you send out your 
contract requirements to sellers. They bid for the chance to work with you. 
You pick the best one, and then you sign the contract with them. Once the 
work begins, you monitor it to make sure the contract is being followed. 
When the work is done, you close out the contract and fill out all the 
paperwork. 


You will need to start with a plan for the whole project. You need to think 
about all of the work that you will contract out for your project before you 
do anything else. You will want to plan for any purchases and acquisitions. 
Here’s where you take a close look at your needs, to be sure that you really 
need to create a contract. You figure out what kinds of contracts make sense 
for your project, and you try to define all of the parts of your project that 
will be contracted out. 


Contract planning is where you plan out each individual contract for the 
project work. You work out how you manage the contract, what metrics it 
will need to meet to be considered successful, how you’|I pick a seller, and 
how you’ll administer the contract once the work is happening. 


The procurement management plan details how the procurement process 
will be managed. It includes the following information: 


The types of contracts you plan to use, and any metrics that will be 
used to measure the contractor’s performance. 

The planned delivery dates for the work or products you are 
contracting. 

The company’s standard documents you will use. 

How many vendors or contractors are involved and how they will be 
managed. 

How purchasing may impact the constraints and assumptions of the 
project plan. 

Coordination of purchasing lead times with the development of the 
project schedule. 

Identification of prequalified sellers (if known). 


The procurement management plan like all other management plans 
becomes a subsidiary of the project management plan. Some tools and 
techniques you may use during the procurement planning stage include 
make or buy analysis and defining the contract type. 


Make or buy analysis 


This means figuring out whether or not you should be contracting the work 
or doing it yourself. It could also mean deciding whether to build a solution 
to your problem or buy one that is already available. Most of the same 
factors that help you make every other major project decision will help you 
with this one. How much does it cost to build it as opposed to buy it? How 
will this decision affect the scope of your project? How about project 
schedule? Do you have time to do the work and still meet your 

commitments? As you plan out what you will and won’t contract, you need 
to have thought through your reasoning pretty carefully. 


There are some resources (like heavy equipment) that your company can 
buy, rent, or lease depending on the situation. You’|l need to examine 
leasing versus buying costs and determine the best way to go forward. 


Contract types 


You should know a little bit about the major kinds of contracts available to 
you so that you choose the one that creates the most fair and workable deal 
for you and the contractor. Some contracts are fixed price: no matter how 
much time or effort goes into them, you always pay the same ((link]). Some 
are cost reimbursable also called cost plus ({link]). This is where the seller 
charges you for the cost of doing the work plus some fee or rate. The third 
major kind of contract is time and materials ({link]). That’s where the buyer 
pays a rate for the time spent working on the project and also pays for all 
the materials used to do the work. 


Cost (revenue) 


Effort 


A fixed price contract the cost 
(or revenue to the vendor) is 
constant regardless of effort 

applied or delivery date. 


Cost (revenue) 


$$ 


Profit 


Effort 


In a cost reimbursable or cost 
plus contract, the seller is 
guaranteed a specific fee. 


$$ Cost (revenue) 


Profit 


Effort 


In a time and materials contract 
the cost (or revenue to the 
vendor) increases with 
increased effort. 


Risk management planning 


Even the most carefully planned project can run into trouble. No matter 
how well you plan, your project can always run into unexpected problems. 
Team members get sick or quit, resources that you were depending on turn 
out to be unavailable, even the weather can throw you for a loop. For 
example, Hurricane Ike. So does that mean that you’re helpless against 
unknown problems? No! You can use risk planning to identify potential 
problems that could cause trouble for your project, analyze how likely 
they’ Il be to occur, take action to prevent the risks you can avoid, and 
minimize the ones that you can’t. 


A risk is any uncertain event or condition that might affect your project. Not 
all risks are negative. Some events (like finding an easier way to do an 
activity) or conditions (like lower prices for certain materials) can help your 
project. When this happens, we call it an opportunity; but it’s still handled 
just like a risk. 


There are no guarantees on any project. Even the simplest activity can turn 
into unexpected problems. Any time there’s anything that might occur on 
your project and change the outcome of a project activity, we call that a 
risk. A risk can be an event (like a hurricane) or it can be a condition (like 
an important part being unavailable). Either way, it’s something that may or 
may not happen ...but if it does, then it will force you to change the way 
you and your team will work on the project. 


If your project requires that you stand on the edge of a cliff, then there’s a 
risk that you could fall ({link]). If it’s very windy out or if the ground is 
slippery and uneven, then falling is more likely. 


Your project Avoid Mitigate Transfer 


Potential ways to handle risk in a project. 


When you’re planning your project, risks are still uncertain: they haven’t 
happened yet. But eventually, some of the risks that you plan do happen. 
And that’s when you have to deal with them. There are four basic ways to 
handle a risk. 


1. Avoid: The best thing that you can do with a risk is to avoid it. If you 
can prevent it from happening, it definitely won’t hurt your project. 
The easiest way to avoid this risk is to walk away from the cliff 
({link]), but that may not be an option on this project. 

2. Mitigate: If you can’t avoid the risk, you can mitigate it. This means 
taking some sort of action that will cause it to do as little damage to 
your project as possible ({link]). 

3. Transfer: One effective way to deal with a risk is to pay someone else 
to accept it for you ([link]). The most common way to do this is to buy 
insurance. 

4. Accept: When you can’t avoid, mitigate, or transfer a risk, then you 
have to accept it ({link]). But even when you accept a risk, at least 
you’ve looked at the alternatives and you know what will happen of it 
occurs. If you can’t avoid the risk, and there’s nothing you can do to 
reduce its impact, then accepting it is your only choice. 


By the time a risk actually occurs on your project, it’s too late to do 
anything about it. That’s why you need to plan for risks from the beginning 


and keep coming back to do more planning throughout the project. 


The risk management plan tells you how you’re going to handle risk in your 
project. It documents how you’ ll access risk on the project, who is 
responsible for doing it, and how often you’ll do risk planning (since you’ ll 
have to meet about risk planning with your team throughout the project.) 


The plan has parts that are really useful for managing risks. 


e Risk categories that you’ll use to classify your risks. Some risks are 
technical, like a component that might turn out to be difficult to use. 
Others are external, like changes in the market or even problems with 
the weather. 

e Risk breakdown structure (RBS) is a great tool for managing your 
risk categories. It looks like a WBS, except instead of tasks it shows 
how the risks break down into categories. 


It’s important to come up with guidelines to help you figure out how big a 
risk’s impact is. The impact tells you how much damage the risk will cause 
to your project. A lot of projects classify impact on a scale from minimal to 
severe, or from very low to very high. The plan should also give you a scale 
to help figure out the probability of the risk. Some risks are very likely; 
others aren’t. 


Quality planning 


It’s not enough to make sure you get it done on time and under budget. You 
need to be sure you make the right product to suit your stakeholders’ needs. 
Quality means making sure that you build what you said you would and that 
you do it as efficiently as you can. That means trying not to make too many 
mistakes and always keeping your project working toward the goal of 
creating the right product! 


Everybody “knows” what quality is. But the way the word is used in 
everyday life is a little different that how it is used in project management. 
Just like the tripe constraint, scope, cost, and schedule- you manage quality 
on your project by setting goals and taking measurements. That’s why you 


need to understand the quality levels your stakeholders believe are 
acceptable, and that your projects meet those targets; just like it needs to 
meet their budget and schedule goals. 


¢ Customer satisfaction is about making sure that the people who are 
paying for the end product are happy with what they get. When the 
team gathers requirements for the specification, they try to write down 
all of the things that the customers want in the product so that you 
know how to make them happy. Some requirements can be left 
unstated, too. Those are the ones that are implied by the customer’s 
explicit needs. For example: some requirements are just common 
sense, like a product that people hold can’t be made from toxic 
chemicals that kill you. It might not be stated, but it’s definitely a 
requirement! 

e Fitness to use is about making sure that the product you build has the 
best design possible to fit the customer’s needs. Which would you 
choose: a product that’s beautifully designed, well constructed, solidly 
built and all around pleasant to look at but does not do what you need, 
or a product that does what you want despite being really ugly and 
hard to use? You’ll always choose the product that fits your needs, 
even if it’s seriously limited. That’s why it’s important that the product 
both does what it is supposed to do and does it well. For example: you 
could pound in a nail with a screwdriver, but a hammer is better fit for 
the job. 

e Conformance to requirements is the core of both customer 
satisfaction and fitness to use, and is a measure of how well your 
product does what you intend. Above all, your product needs to do 
what you wrote down in your requirements document. Your 
requirements should take into account what will satisfy your customer 
and the best design possible for the job. That means conforming to 
both stated and implied requirements. 


In the end, your product’s quality is judged by whether you built what you 
said you would build. 


Quality planning focuses on taking all of the information available to you at 
the beginning of your project and figuring out how you will measure your 


quality and prevent defects. Your company should have a quality policy that 
tells how it measures quality across the organization. You should make sure 
your project follows the company policy and any governmental rules or 
regulations on how you need to plan quality for your project. 


You need to plan out which activities you’re going to use to measure the 
quality of the product of your project. And you need to be sure the activities 
you plan are going to pay off in the end. So you’|l need to think about the 
cost of all the quality-related activities you want to do. Then you’!l need to 
set some guidelines for what you going to measure against. Finally, you’ ll 
need to design the tests you’re going to run when the product is ready to be 
tested. 


Quality planning tools 


The following represents the quality planning tools available to the project 
manager. 


¢ Cost benefit analysis is looking at how much your quality activities 
will cost versus how much you will gain from doing them. The costs 
are easy to measure; the effort and resources it takes to do them are 
just like any other task on your schedule. Since quality activities don’t 
actually produce a product, it is harder for people to measure the 
benefit sometimes. The main benefits are less re-work, higher 
productivity and efficiency and more satisfaction from both the team 
and the customer. 

¢ Benchmarking means using the results of quality planning on other 
projects to set goals for your own. You might find that the last project 
in your company had 20% fewer defects than the one before it. You 
should want to learn from a project like that and put in practice any of 
the ideas they used to make such a great improvement. Benchmarks 
can give you some reference points for judging your own project 
before you even get started with the work. 

¢ Design of experiments is the list of all the kinds of tests you are going 
to run on your product. It might list all the kinds of test procedures 


you’ ll do, the approaches you’!l take, and even the tests themselves. 
(In the software world, this is called test planning). 

¢ Cost of quality is what you get when you add up the cost of all the 
prevention and inspection activities you are going to do on your 
project. It doesn’t just include the testing. It includes any time spent 
writing standards, reviewing documents, meeting to analyze the root 
causes of defects, re-work to fix the defects once they’re found by the 
team; absolutely everything you do to ensure quality on the project. 


Cost of quality can be a good number to check whether your project is 
doing well or having trouble. Say your company tracks cost of quality on all 
of its projects. Then you could tell if you were spending more or less than 
they are to get your project up to quality standards. 


Once you have your quality plan, you know your guidelines for managing 
quality on your project. Your strategies for monitoring your project quality 
should be included in the plan, as well as the reasons for all the steps you 
are taking. It’s important that everyone on the team understand the rationale 
behind the metrics being used to judge success or failure of the project. 


Communication planning 


Communications management is about keeping everybody in the loop. 
Have you ever tried talking to someone in a really loud, crowded room? 
That’s what running a project is like if you don’t get a handle on 
communications. The communications planning process concerns defining 
the types of information you’re going to deliver, to whom, the format for 
communicating the information and when. It turns out that 90% of a project 
manager’s job is spent on communication so it’s important to make sure 
everybody gets the right message at the right time. 


The first step in defining your communication plan is figuring out what 
kind of communication your stakeholders need from the project so that they 
can make good decisions. This is called the communications requirements 
analysis. Your project will produce a lot of information; you don’t want to 
overwhelm your stakeholders with all of it. Your job here is to figure out 
what they feel is valuable. Communicating valuable information doesn’t 


mean you always paint a rosy picture. Communications to stakeholders may 
consist of either good news or bad news- the point is that you don’t want to 
bury stakeholders in too much information but give them enough so that 
they’re informed and can make appropriate decisions. 


Communications technology has a major impact on how you can keep 
people in the loop. This examines the methods (or technology) used to 
communicate the information to, from and among the stakeholders. 
Methods of communicating can take many forms, such as written, spoken, 
e-mail, formal status reports, meetings, online databases, online schedules, 
project websites and so forth. You should consider several factors before 
deciding what methods you’!l choose to transfer information. The timing of 
the information exchange or need for updates is the first factor. It’s a lot 
easier for people to get information on their projects if it’s accessible 
through a web site, than if all your information is passed around by paper 
memos. Do you need to procure new technology or systems, or are there 
systems already in place that will work? The technologies available to you 
will definitely figure into your plan of how you will keep everyone notified 
of project status and issues. Staff experience with the technology is another 
factor. Are there project team members and stakeholders experienced at 
using this technology, or will you need to train them? Finally, consider the 
duration of the project and the project environment. Will the technology 
you’re choosing work throughout the life of the project or will it have to be 
upgraded or updated at some point? And how does the project team 
function? Are they located together or spread out across several campuses 
or locations? The answers to these questions should be documented in the 
communication plan. 


All projects require sound communication plans, but not all projects will 
have the same types of communication or the same methods for distributing 
the information. The communication plan documents the types of 
information needs the stakeholders have, when the information should be 
distributed and how the information will be delivered. 


The type of information you will typically communicate includes project 
status, project scope statements, and scope statement updates, project 
baseline information, risks, action items, performance measures, project 


acceptance and so on. What’s important to know now is that the information 
needs of the stakeholders should be determined as early in the planning 
phase of the project management lifecycle as possible so that as you and 
your team develop project planning documents, you already know who 
should receive copies of them and how they should be delivered. 


Bringing it all together 


Believe it or not, we have officially completed the planning phase of the 
project management lifecycle. The project plan is the approved, formal, 
documented plan that’s used to guide you throughout the project execution 
phase. The plan is made up of all the processes of the planning phase. It is 
the map that tells you where you’re going and how to perform the activities 
of the project plan during the project execution phase. It serves several 
purposes; the most important of which is tracking and measuring project 
performance. The project plan is critical in all communications you’!l have 
from here forward with the stakeholders, management, and customers. The 
project plan encompasses everything we talked about up to now and is 
represented in a formal document or collection of documents. This 
document contains the project scope, deliverables, assumptions, risks, 
WBS, milestones, project schedule, resources, communication plan, the 
project budget and any procurement needs. It becomes the baseline you’ ll 
use to measure and track progress against. It is also used to help you control 
the components that tend to stray away from the original plan so you can 
get them back on track. 


The project plan is used as a communication and information tool for 
stakeholders, team members and the management team. They will use the 
project plan to review and gauge progress as well. Your last step in the 
planning phase is obtaining sign-off of the project plan from stakeholders, 
the sponsor and the management team. If they’ve been an integral part of 
the planning processes all along (and I know you know how important this 
is), obtaining sign-off of the project plan should simply be a formality. 
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Project Execution 


After you have carefully planned your project, you will be ready to start the 
project execution phase, the third phase of the project management life 
cycle. The execution phase involves putting the project plan into action. It’s 
here that the project manager will coordinate and direct project resources to 
meet the objectives of the project plan. As the project unfolds, it’s the 
project manager’s job to direct and manage each activity on the project, 
every step of the way. That’s what happens in the execution phase of the 
project lifecycle; you simply follow the plan you’ve put together and handle 
any problems that come up. 


The execution phase is where you and your project team actually do the 
project work to produce the deliverables. The word deliverable means 
anything your project delivers. The deliverables for your project include all 
of the products or services that you and your team are performing for the 
client, customer or sponsor including all the project management 
documents that you put together. 


The steps undertaken to build each deliverable will vary depending on the 
type of project you are undertaking, and cannot therefore be described here 
in any real detail. For instance engineering and telecommunications projects 
will focus on using equipment, resources and materials to construct each 
project deliverable, whereas computer software projects may require the 
development and implementation of software code routines to produce each 
project deliverable. The activities required to build each deliverable will be 
clearly specified within the project requirements document and project plan 
accordingly. 


Your job as project manager is to direct the work, but you need to do more 
than deliver the results. You also need to keep track of how well your team 
performed. The executing phase keeps the project plan on track with careful 
monitoring and control processes to ensure the final deliverable meets the 
acceptance criteria set by the customer. This phase is typically where 
approved changes are implemented. 


Most often changes are identified through looking at performance and 
quality control data. Routine performance and quality control measurements 


should be evaluated on a regular basis throughout the execution phase. 
Gathering reports on those measurements will help you determine where 
the problem is and recommend changes to fix it. 


Change control 


When you find a problem, you can’t just make a change, because what if 
it’s too expensive, or will it take too long? You will need to look at how it 
affects the triple constraint (time, cost, scope) and how they impact quality. 
You will then have to figure out if it is worth making the change. Change 
control is a set of procedures that let you make changes in an organized 
way. 


Anytime you need to make a change to your plan, you need to start with a 
change request ({link]). This is a document that either you or the person 
making the request needs to create. Any change to your project needs to be 
documented so you can figure out what needs to be done, by when, and by 
whom. 


Is it too late to add the client’s 
wish list of features to the 
project? 


Once the change request is documented, it is submitted to a change control 
board. A change control board is a group of people who consider changes 
for approval. Not every change control system has a board but most do. The 
change request could also be submitted to the project sponsor or 
management for review and approval. Putting the recommended changes 
through change control will help you evaluate the impact and update all the 
necessary documents. Not all changes are approved, but if the changes and 
repairs are approved, you send them back to the team to put them in place. 


The execution phase will utilize the most project time and resources and as 
a result, costs are usually the highest during the executing phase. Project 
managers will also experience the greatest conflicts over schedules in this 
phase. You may find as your monitoring your project, the actual time it is 
taking to do the scheduled work is taking longer than the amount of time 
you planned. If you evaluate the impact of the change and find that it won’t 
have an impact on the project triple constraint, then you can make the 
change without going through change control. 


When you absolutely have to meet the date and you are running behind, you 
can sometimes find ways to do activities more quickly by adding more 
resources to critical path tasks. That’s calledcrashing. Crashing the schedule 
means adding resources or moving them around to shorten it. Crashing 
ALWAYS costs more and doesn’t always work! There’s no way to crash a 
schedule without raising the overall cost of the project. So, if the budget is 
fixed and you don’t have any extra money to spend, you can’t use this 
technique. 


Sometimes you’ve got two activities planned to occur in sequence, but you 
can actually do them at the same time. This is called fast-tracking the 
project. On a software project, you might do both your user acceptance 
testing (UAT) and your functional testing at the same time, for example. 
This is pretty risky. There’s a good chance you might need to redo some of 
the work you have done concurrently. Crashing and fast tracking are 
schedule compression tools. Managing schedule change means keeping all 
of your schedule documents up to date. That way, you will always be 
comparing your results to the right plan. 


After the deliverables have been physically constructed and accepted by the 
customer a phase review is carried out to determine whether the project is 
complete and ready for closure. 


Project Closeout 


Every project needs to end and that’s what project closeout is all about in 
the last phase of the project lifecycle. The whole point of the project is that 
you need to deliver what you promised. By making sure you delivered 
everything you said you would, you make sure that all stakeholders are 
satisfied and all acceptance criteria has been met. Once that happens, your 
project can finish ([link]). 


RIGHT, NEXT 

PROJECT YOU GET 

LESS TIME AND 
LESS MONEY ! 


I FINISHED THE 
PROJECT ON TIME 
AND ON BUDGET ! 


The potential unwanted consequences 
of finishing a project on time and 
within budget! 


Project closeout is often the most often neglected phase of all the project 
lifecycle. Once the project is over, it’s easy to pack things up, throw some 
files in a drawer, and start moving right into the initiation phase of the next 
project. Hold on! You’re not done yet! 


The key activity in project closeout is gathering project records and 
disseminating information to formalize acceptance of the product, service 
or project as well as to perform project closure. As the project manager, you 
will want to review project documents to make certain they are up-to-date. 
For example, perhaps some scope change requests were implemented that 


changed some of the characteristics of the final product. The project 
information you are collecting during this phase should reflect the 
characteristics and specifications of the final product. Don’t forget to update 
your resource assignments as well. Some team members will have come 
and gone over the course of the project; you need to double-check that all 
the resources and their roles and responsibilities are noted. 


Once the project outcomes are documented, you’|l request formal 
acceptance from the stakeholders or customer. They’re interested in 
knowing if the product or service of the project meets the objectives the 
project set out to accomplish. If your documentation is up-to-date, you’ ll 
have the project results at hand to share with them. 


Lessons learned 


Project closeout is also concerned with analyzing the project management 
processes to determine their effectiveness and to document lessons learned. 
Lessons learned are used to document the successes and failures of the 
project. As an example, lessons learned document the reasons why specific 
corrective actions were taken, their outcomes, the causes of performance 
variances, unplanned risks that occurred, mistakes that were made and 
could have been avoided and so on. 


Unfortunately, sometimes projects do fail. There are things that can be 
learned from the failure of a project (as well from successful projects), and 
this information should be documented for future reference. Lessons 
learned can be some of the most valuable information you’ll take away 
from any project. We can all learn from our experiences, and what better 
way to have more success on your next project than to review a similar past 
project’s lessons learned document? But it is important not to forget the 
lessons learned! 


Contract closure 


Contracts come to a close just as projects come to a close. Contract closure 
is concerned with completing and settling the terms of the contract. It 
supports the project closeout process because the contract closure process 


determines if the work described in the contract was completed accurately 
and satisfactorily. Keep in mind that not all projects are performed under 
contract so not all projects require the contract closure process. Obviously, 
this process applies only to those phases, deliverables or portions of the 
project that were performed under contract. 


Contract closure updates the project records detailing the final results of the 
work on the project. Contracts may have specific terms or conditions for 
completion and closeout. You should be aware of these terms or conditions 
so that project closeout isn’t held up because you missed an important 
detail. If you are administering the contract yourself, be sure to ask your 
procurement department if there are any special conditions that you should 
be aware of so that your project team doesn’t inadvertently delay contract 
project closure. 


One of the purposes of contract closure process is to provide formal notice 
to the seller- usually in written form, that the deliverables are acceptable 
and satisfactory or have been rejected. If the product or service does not 
meet the expectations, the vendor will need to correct the problems before 
you issue a formal acceptance notice. Hopefully, quality audits have been 
performed during the course of the project and the vendor was given the 
opportunity to make corrections earlier in the process than the closing 
phase. It’s not a good idea to wait until the very end of the project and then 
spring all the problems and issues on the vendor at once. It’s much more 
efficient to discuss problems with your vendor as the project progresses 
because it provides the opportunity for correction when the problems occur. 


If the product or service does meet the project’s expectation and is 
acceptable, formal written notice to the seller is required indicating that the 
contract is complete. This is the formal acceptance and closure of the 
contract. It’s your responsibility as the project manager to document the 
formal acceptance of the contract. Many times the provisions for 
formalizing acceptance and closing the contract are spelled out in the 
contract itself. 


If you have a procurement department handling the contract administration, 
they will expect you to inform them when the contract is complete and will 
in turn follow the formal procedures to let the seller know the contract is 


complete. However, you’|I still note the contract completion in your copy of 
the project records. 


Releasing project team 


Releasing project team members is not an official process. However, it 
should be noted that at the conclusion of the project, you will release your 
project team members, and they will go back to their functional managers 
or get assigned to a new project. You will want to keep their managers, or 
other project managers, informed as you get closer to project completion, so 
that they have time to adequately plan for the return of their employees. 
Start letting them know a few months ahead of time what the schedule 
looks like and how soon they can plan on using their employees on new 
projects. This gives the other managers the ability to start planning 
activities and scheduling activity dates. 


Celebrate! 


The project team should celebrate their accomplishment, and the project 
manager should officially recognize their efforts and thank them for their 
participation and officially close the project. A celebration helps team 
members formally recognize the project end and brings closure to the work 
they’ve done. It also encourages them to remember what they’ve learned 
and to start thinking about how their experiences will benefit them and the 
organization during the next project ((link]). 
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Celebrate! Your project is 
over... at least until the next 
one. 


A Glossary of Project Management Terms 


Every discipline has its own vocabulary, and project management is no 
exception. Part of the process of successfully deploying project 
Management in your organization is to standardize the terminology. That 
way, when one person talks about risks, scope, issues, requirements, and 
other project management concerns, everyone else knows what he or she is 
referring to. This glossary contains common terms used in project 
management and can help start the standardization process. 


Assumption 


There may be external circumstances or events that must occur for the 
project to be successful (or that should happen to increase your chances of 
success). If you believe that the probability of the event occurring is 
acceptable, you could list it as an assumption. An assumption has a 
probability between 0 and 100%. That is, it is not impossible that the event 
will occur (0%) and it is not a fact (100%). It is somewhere in between. 
Assumptions are important because they set the context in which the entire 
remainder of the project is defined. If an assumption doesn't come through, 
the estimate and the rest of the project definition may no longer be valid. 


BAC 


Budget at completion (BAC) is the sum of all budgets allocated to a project. 


Backward pass 


Calculation of the latest finish times by working from finish-to-start for the 
uncompleted portion of a network of activities. 


Balanced matrix 


An organizational matrix where functions and projects have the same 
priority. 


Bar chart 


A view of the project schedule that uses horizontal bars on a time scale to 
depict activity information; frequently called a Gantt chart. 


Baseline 


The value or condition against which all future measurements will be 
compared. 


Baseline cost 


The amount of money an activity was intended to cost when the baseline 
plan was established. 


Baseline dates 


Original planned start and finished dates for an activity. Used to compare 
with current planned dates to determine any delays. Also used to calculate 
budgeted cost of work scheduled in earned value analysis. 


Baseline plan 


The original plan (for a project, a work package, or an activity), plus or 
minus approved changes. Usually used with a modifier, e.g., cost baseline, 
schedule baseline, performance measurement baseline, etc. 


Best practices 


Techniques that agencies may use to help detect problems in the acquisition, 
management, and administration of service contracts. Best practices are 
practical techniques gained from experience that have been shown to 
produce best results. 


Beta testing 


Pre-release testing in which a sampling of the intended customer base tries 
out the product. 


Bottom-up cost estimate 
The approach to making a cost estimate or plan in which detailed estimates 


are made for every task shown in the work breakdown structure and then 
summed to provide a total cost estimate or plan for the project. 


Brainstorming 
The unstructured and dynamic generation of ideas by a group of people 


where anything and everything is acceptable, particularly useful in 
generating a list of potential project risks. 


Budget 


Generally refers to a list of all planned expenses and revenues. 


Budgeted cost of work performed (BCWP) 


Measures the budgeted cost of work that has actually been performed, 
rather than the cost of work scheduled. 


Budgeted cost of work scheduled (BCWS) 
The approved budget that has been allocated to complete a scheduled task, 


or work breakdown structure (WBS) component, during a specific time 
period. 


Business analysis 


Is the set of tasks, knowledge, and techniques required to identify business 
needs and determine solutions to business problems. Solutions often include 


a systems development component, but may also consist of process 
improvement or organizational change. 


Business area 


The part of the organization containing the business operations affected by 
a program or project. 


Business case 
A document developed towards the end of the concept phase, to establish 


the merits and desirability of the project and justification for further project 
definition. 


Business needs 


The requirements of an enterprise to meet its goals and objectives. 


Business operations 


The ongoing recurring activities involved in the running of a business for 
the purpose of producing value for the stakeholders. They are contrasted 
with project management, and consist of business processes. 


Business process 


A collection of related, structured activities or tasks that produce a specific 
service or product (serve a particular goal) for a particular customer or 
customers. There are three types of business processes: management 
processes, operational processes, and supporting processes. 


Case study 


A research method which involves an in-depth, longitudinal examination of 
a single instance or event: a case. They provide a systematic way of looking 


at events, collecting data, analyzing information, and reporting the results. 


Champion 


An end user representative, often seconded into a project team. Someone 
who acts as an advocate for a proposal or project. 


Change control 
A general term describing the procedures used to ensure that changes 
(normally, but not necessarily, to IT systems) are introduced in a controlled 


and coordinated manner. Change control is a major aspect of the broader 
discipline of change management. 


Change management 


The formal process through which changes to the project plan are approved 
and introduced. 


Change order 


A document that authorizes a change in some aspect of the project. 


Change request 


A request needed to obtain formal approval for changes to the scope, 
design, methods, costs, or planned aspects of a project. Change requests 
may arise through changes in the business or issues in the project. Change 
requests should be logged, assessed and agreed on before a change to the 
project can be made. 


Child activity 


Subordinate task belonging to a parent task existing at a higher level in the 
work breakdown structure. 


Client/customers 


The person or group that is the direct beneficiary of a project or service is 
the client/customer. These are the people for whom the project is being 
undertaken (indirect beneficiaries are stakeholders). In many organizations, 
internal beneficiaries are called clients and external beneficiaries are called 
customers, but this is not a hard and fast rule. 


Constraints 


Constraints are limitations that are outside the control of the project team 
and need to be managed around. They are not necessarily problems. 
However, the project manager should be aware of constraints because they 
represent limitations that the project must execute within. Date constraints, 
for instance, imply that certain events (perhaps the end of the project) must 
occur by certain dates. Resources are almost always a constraint, since they 
are not available in an unlimited supply. 


Critical path 

The critical path is the sequence of activities that must be completed on 
schedule for the entire project to be completed on schedule. It is the longest 
duration path through the workplan. If an activity on the critical path is 


delayed by one day, the entire project will be delayed by one day (unless 
another activity on the critical path can be accelerated by one day). 


Closeout 


The completion of all work on a project. 


Communication plan 


A statement of project’s stakeholders’ communication and information 
needs. 


Concept phase 


The first phase of a project in the generic project lifecycle, in which the 
need is examined, alternatives are assessed, the goals and objectives of the 
project are established and a sponsor is identified. 


Confidence level 


A level of confidence, stated as a percentage, for a budget or schedule 
estimate. The higher the confidence level, the lower the risk. 


Conflict management 


Handling of conflicts between project participants or groups in order to 
create optimal project results. 


Conflict resolution 


To seek a solution to a problem, five methods in particular have been 
proven through confrontations, compromise, smoothing, forcing and 
withdrawal. 


Constraints 


Constraints are limitations that are outside the control of the project team 
and need to be managed around. They are not necessarily problems. 
However, the project manager should be aware of constraints because they 
represent limitations that the project must execute within. Date constraints, 
for instance, imply that certain events (perhaps the end of the project) must 
occur by certain dates. Resources are almost always a constraint, since they 
are not available in an unlimited supply. 


Contingencies 


A Contingency is the planned allotment of time and cost for unforeseeable 
elements with a project. Including contingencies will increase the 
confidence of the overall project. 


Control 


The process of comparing actual performance with planned performance, 
analyzing the differences, and taking the appropriate corrective action. 


Costs 


The cost value of project activity. 


Costs budgeting 


The allocation of cost estimates to individual project components. 


Cost overrun 


The amount by which actual costs exceed the baseline or approved costs. 


Crashing 


The process of reducing the time it takes to complete an activity by adding 
resources. 


Critical 


An activity or event that, if delayed, will delay some other important event, 
commonly the completion of a project or a major milestone in a project. 


Critical path method (CPM) 


A mathematically based modeling technique for scheduling a set of project 
activities, used in project management. 


Critical chain project management (CCPM) 


A method of planning and managing projects that puts more emphasis on 
the resources required to execute project tasks. 


Critical success factors 


The key factors that are deemed critical to the success of the project. The 
nature of these factors will govern the response to conflicts, risks and the 
setting of priorities. 


Culture 


A person's attitudes arising out of their professional, religious, class, 
educational, gender, age and other backgrounds. 


Customer 


See client. 


Deliverable 


A deliverable is any tangible outcome that is produced by the project. All 
projects create deliverables. These can be documents, plans, computer 
systems, buildings, aircraft, etc. Internal deliverables are produced as a 
consequence of executing the project and are usually needed only by the 
project team. External deliverables are those that are created for clients and 
stakeholders. Your project may create one or many deliverables. 


Dependency 


Dependencies on a project are the relationships between activities whereby 
one activity must do something (finish-to-start) before another activity can 
do something (start-to-finish). 


Duration 
The duration of a project's terminal element is the number of calendar 


periods it takes from the time the execution of element starts to the moment 
it is completed. 


Earned value management (EVM) 
A project management technique for measuring project progress in an 


objective manner, with a combination of measuring scope, schedule, and 
cost in a single integrated system. 


Earned schedule (ES) 
An extension to earned value management (EVM), which renames two 


traditional measures, to indicate clearly they are in units of currency or 
quantity, not time. 


Estimation 


In project management it is the processes of making accurate estimates 
using the appropriate techniques. 


Event chain diagram 


A diagram that show the relationships between events and tasks and how 
the events affect each other. 


Event chain methodology 
An uncertainty modeling and schedule network analysis technique that is 


focused on identifying and managing events and event chains that affect 
project schedules. 


Float 


In a project network is the amount of time that a task in a project network 
can be delayed without causing a delay to subsequent tasks and or the 
project completion date. 


Functional manager 


The functional manager is the person you report to within your functional 
organization. Typically, this is the person who does your performance 
review. The project manager may also be a functional manager, but he or 
she does not have to be. If your project manager is different from your 
functional manager, your organization is probably utilizing matrix 
management. 


Gantt, Henry 


An American mechanical engineer and management consultant, who 
developed the Gantt chart in the 1910s. 


Gantt chart 


A Gantt chart is a bar chart that depicts activities as blocks over time. The 
beginning and end of the block correspond to the beginning and end-date of 
the activity. 


Goal 


An objective that consists of a projected state of affairs which a person or a 
system plans or intends to achieve or bring about a personal or 
organizational desired end-point in some sort of assumed development. 
Many people endeavor to reach goals within a finite time by setting 
deadlines. 


Goal setting 


Involves establishing specific, measurable and time targeted objectives. 


Graphical evaluation and review technique (GERT) 


A network analysis technique that allows probabilistic treatment of both 
network logic and activity duration estimated. 


Hammock activity 
A schedule (project management) or project planning term for a grouping of 


subtasks that hangs between two end dates it is tied to. or the two end 
events it is fixed to. 


ISO 10006 


A guideline for quality management in projects, is an international standard 
developed by the International Organization for Standardization. 


Issue 
An issue is a major problem that will impede the progress of the project and 
that can't be resolved by the project manager and project team without 


outside help. Project managers should proactively deal with issues through 
a defined issues management process. 


Kickoff meeting 


The first meeting with the project team and the client of the project. 


Level of effort (LOE) 
Is qualified as a support type activity which doesn't lend itself to 


measurement of a discrete accomplishment. Examples of such an activity 
may be project budget accounting, customer liaison, etc. 


Life cycle 


Life cycle refers to the process used to build the deliverables produced by 
the project. Every project has an inception, a period during which activities 
move the project toward completion, and a termination (either successful or 
unsuccessful). Taken together, these phases represent the path a project 
takes from the beginning to its end and are generally referred to as the 
project life cycle. The project life cycle is often formally divided into 
phases that describe common activities as the project matures. 


Management 


In business and human organization activity is simply the act of getting 
people together to accomplish desired goals. Management comprises 
planning, organizing, staffing, leading or directing, and controlling an 
organization (a group of one or more people or entities) or effort for the 
purpose of accomplishing a goal. 


Management process 


A process of planning and controlling the performance or execution of any 
type of activity. 


Motivation 


Is the set of reasons that determines one to engage in a particular behavior. 


Milestone 


A milestone is a scheduling event that signifies the completion of a major 
deliverable or a set of related deliverables. A milestone, by definition, has 
duration of zero and no effort. There is no work associated with a 
milestone. It is a flag in the work plan to signify that some other work has 
completed. Usually, a milestone is used as a project checkpoint to validate 
how the project is progressing. In many cases there is a decision, such as 
validating that the project is ready to proceed further, that needs to be made 
at a milestone. 


Objective 


An objective is a concrete statement that describes what the project is trying 
to achieve. The objective should be written at a low level, so that it can be 
evaluated at the conclusion of a project to see whether it was achieved. 
Project success is determined based on whether the project objectives were 
achieved. A technique for writing an objective is to make sure it is specific, 
measurable, acceptable, realistic, and time based (SMART). 


Operations management 


An area of business that is concerned with the production of good quality 
goods and services, and involves the responsibility of ensuring that business 
operations are efficient and effective. It is the management of resources, the 
distribution of goods and services to customers, and the analysis of queue 
systems. 


Organization 


A social arrangement which pursues collective goals, which controls its 
own performance, and which has a boundary separating it from its 
environment. 


Planning 


Planning in project management consists of processes that involve 
formulating and revising project goals and objectives and creating the 
project management plan that will be used to achieve the goals the project 
was undertaken to address. Planning involves determining alternative 
courses of action and selecting from among the best of those to produce the 
project's goals. 


Process 


An ongoing collection of activities, with an inputs, outputs and the energy 
required to transform inputs to outputs. 


Program 


A program is the umbrella structure established to manage a series of 
related projects. The program does not produce any project deliverables. 
The project teams produce them all. The purpose of the program is to 
provide overall direction and guidance, to make sure the related projects are 
communicating effectively, to provide a central point of contact and focus 
for the client and the project teams, and to determine how individual 
projects should be defined to ensure that all the work gets completed 
successfully. 


Program management 


The process of managing multiple ongoing inter-dependent projects. An 
example would be that of designing, manufacturing and providing support 
infrastructure for an automobile manufacturer. 


Program manager 


A program manager is the person with the authority to manage a program. 
(Note that this is a role. The program manager may also be responsible for 
one or more of the projects within the program.) The program manager 
leads the overall planning and management of the program. All project 
managers within the program report to the program manager. 


Project 


A project is a temporary endeavor undertaken to accomplish a unique 
product or service with a defined start and end point and specific objectives 
that, when attained, signify completion. 


Project definition (project charter) 


Before you start a project, it is important to know the overall objectives of 
the project, as well as the scope, deliverables, risks, assumptions, project 
organization chart, etc. The project definition (or project charter) is the 


document that holds this relevant information. The project manager is 
responsible for creating the project definition. The document should be 
approved by the sponsor to signify that the project manager and the sponsor 
are in agreement on these important aspects of the project. 


Project manager 


The project manager is the person with the authority to manage a project. 
The project manager is 100 percent responsible for the processes used to 
manage the project. He or she also has people management responsibilities 
for team members, although this is shared with the team member's 
functional manager. The processes used to manage the project include 
defining the work, building the work plan and budget, managing the work 
plan and budget, scope management, issues management, risk management, 
etc. 


Project management 
Project management is the application of knowledge, skills, tools, and 


techniques applied to project activities in order to meet or exceed 
stakeholder needs and expectations from a project. 


Project management body of knowledge (PMBOK) 


The sum of knowledge within the profession of project management that is 
standardized by ISO. 


Project management professional 


A certificated professional in project management. 


Project management software 


A type of software, including scheduling, cost control and budget 
management, resource allocation, collaboration software, communication, 


quality management and documentation or administration systems, which 
are used to deal with the complexity of large projects. 


Project phase 


A phase is a major logical grouping of work on a project. It also represents 
the completion of a major deliverable or set of related deliverables. On an 
IT development project, logical phases might be planning, analysis, design, 
construct (including testing), and implementation. 


Project plan 


A formal, approved document used to guide both project execution and 
project control. The primary uses of the project plan are to document 
planning assumptions and decisions, facilitate communication among 
stakeholders, and document approved scope, cost, and schedule baselines. 
A project plan may be summary or detailed. 


Project planning 


A part of project management, which relates to the use of schedules such as 
Gantt charts to plan and subsequently report progress within the project 
environment. 


Project team 


The project team consists of the full-time and part-time resources assigned 
to work on the deliverables of the project. They are responsible for 
understanding the work to be completed; completing assigned work within 
the budget, timeline, and quality expectations; informing the project 
manager of issues, scope changes, and risk and quality concerns; and 
proactively communicating status and managing expectations. 


Quality 


The standards and criteria to which the project’s products must be delivered 
for them to perform effectively. First, the product must perform to provide 
the functionality expected, and to solve the problem, and deliver the benefit 
and value expected of it. It must also meet other performance requirements, 
or service levels, such as availability, reliability and maintainability, and 
have acceptable finish and polish. Quality on a project is controlled through 
quality assurance (QA) which is the process of evaluating overall project’s 
performance on a regular basis to provide confidence that the project will 
satisfy the relevant quality standards. 


Requirements 


Requirements are descriptions of how a product or service should act, 
appear, or perform. Requirements generally refer to the features and 
functions of the deliverables you are building on your project. 
Requirements are considered to be a part of project scope. High-level scope 
is defined in your project definition (charter). The requirements form the 
detailed scope. After your requirements are approved, they can be changed 
through the scope change management process. 


Resources 


Resources are the people, equipment, and materials needed to complete the 
wrok of the project. 


Risk 


There may be potential external events that will have a negative impact on 
your project if they occur. Risk refers to the combination of the probability 
the event will occur and the impact on the project if the event occurs. If the 
combination of the probability of the occurrence and the impact to the 
project is too high, you should identify the potential event as a risk and put 
a proactive plan in place to manage the risk. 


Risk management planning 


The process that determines how risks will be managed for a project. It 
describes how risks are defined, monitored, and controlled throughout the 
project. 


Schedule development 


This process calculates and prepares the schedule of project activities, 
which becomes the schedule baseline. It determines activity start and finish 
dates, finalizes activity sequences and durations, and assigns resources to 
activities. 


Scope 


Scope is the way you describe the boundaries of the project. It defines what 
the project will deliver and what it will not deliver. High-level scope is set 
in your project definition (charter) and includes all of your deliverables and 
the boundaries of your project. The detailed scope is identified through your 
business requirements. Any changes to your project deliverables, 
boundaries, or requirements would require approval through scope change 
management. 


Scope creep 
Refers to uncontrolled changes in a project's scope. This phenomenon can 
occur when the scope of a project is not properly defined, documented, or 


controlled. It is generally considered a negative occurrence that is to be 
avoided. 


Six sigma 


A business management strategy, originally developed by Motorola, that 
today enjoys widespread application in many sectors of industry. 


Sponsor (executive sponsor and project sponsor) 


The sponsor is the person who has ultimate authority over the project. The 
executive sponsor provides project funding, resolves issues and scope 
changes, approves major deliverables, and provides high-level direction. He 
or she also champions the project within the organization. Depending on the 
project and the organizational level of the executive sponsor, he or she may 
delegate day-to-day tactical management to a project sponsor. If assigned, 
the project sponsor represents the executive sponsor on a day-to-day basis 
and makes most of the decisions requiring sponsor approval. If the decision 
is large enough, the project sponsor will take it to the executive sponsor. 


Stakeholder 


Specific people or groups who have a stake in the outcome of the project 
are stakeholders. Normally stakeholders are from within the company and 
may include internal clients, management, employees, administrators, etc. 
A project can also have external stakeholders, including suppliers, 
investors, community groups, and government organizations. 


Steering committee 


A steering committee is usually a group of high-level stakeholders who are 
responsible for providing guidance on overall strategic direction. They don't 
take the place of a sponsor but help spread the strategic input and buy-in to 
a larger portion of the organization. The steering committee is especially 
valuable if your project has an impact in multiple organizations because it 
allows input from those organizations into decisions that affect them. 


Systems development lifecycle (SDLC) 


Is any logical process used by a systems analyst to develop an information 
system, including requirements, validation, training, and user ownership. 
An SDLC should result in a high quality system that meets or exceeds 
customer expectations, within time and cost estimates, works effectively 
and efficiently in the current and planned information technology (IT) 
infrastructure, and is cheap to maintain and cost-effective to enhance. 


Tasks 


In project management a task is an activity that needs to be accomplished 
within a defined period of time. 


Task analysis 


The analysis or a breakdown of exactly how a task is accomplished, such as 
what sub-tasks are required. 


Timeline 


A graphical representation of a chronological sequence of events also 
referred to as a chronology. It can also mean a schedule of activities, such as 
a timetable. 


Triple constraint 


Triple constraint is called the scope triangle or the quality triangle. The 
triangle illustrates the relationship between three primary forces in a 
project. Project scope, time and cost--Project quality is affected by 
balancing these three factors. 


Work 


In project management is the amount of effort applied to produce a 
deliverable or to accomplish a task (a terminal element). 


Work breakdown structure (WBS) 


A task oriented family tree of activities which organizes, defines and 
graphically dispays the total work to be accomplished in order to achieve 
the final objectives of a project. It is a system for sub-dividing a project into 
manageable work packages. 


Work package 


A deliverable at the lowest level of a work breakdown structure (WBS). 
They are a group of related tasks that are defined at the same level within 
the WBS. 


Work plan (schedule) 


The project work plan tells you how you will complete the project. It 
describes the activities required, the sequence of the work, who is assigned 
to the work, an estimate of how much effort is required, when the work is 
due, and other information of interest to the project manager. The work plan 
allows the project manager to identify the work required to complete the 
project and also allows the project manager to monitor the work to 
determine whether the project is on schedule. 


